Дейв Катлер

Грант Сейверс: Я Грант Сейверс, довірена особа в Музеї історії комп’ютерів, тут із Дейвом Катлером у його вітальні в Bellevue, в прекрасний день у Сіетлі. Гарна погода, для різноманітності. Я тут, щоб обговорити з Дейвом його довгу кар'єру в комп'ютерній індустрії. І так ми почнемо. Отже, ми говорили про те, як ви познайомилися з комп'ютерами. Але давайте трохи повернемося в раннє дитинство і життя в Мічигані та перебування поблизу завода Oldsmobile в Лансінгу. Тож розкажіть нам трохи про свої ранні роки та середню школу.

Девід Катлер: Я виріс у Девітті, штат Мічіган, приблизно в десяти милях на північ від Лансінгу, де Oldsmobile був. Я ходив до середньої школи Девітта. Я був перш за все спортсменом, а не учнем, хоча мав досить хороші оцінки в Dewitt. Я був спортсменом з відзнаками. Я грав у футбол, баскетбол, бейсбол і бігав трек. І я фанат штату Мічиган. Штат Мічиган був там, у Іст-Лансінгу, тож я виріс поруч Іст-Лансінг і штат Мічиган. Раніше я дуже цікавився моделями літаків і створив їх багато. Хотів стати пілотом, коли виросту. Але чомусь це просто пройшло повзмене. І пізніше я виявив, що у мене проблеми з заколисуванням, так що це не вийде. Так це майже все про її раннє...

Сейверс: Отже, моделі літаків викликали технічний інтерес до авіації та польотів?

Катлер: Я не знаю, як я потрапив у моделі літаків. Був місцевий магазин, який був як хобі магазин, який продавав моделі літаків, і я зацікавився їх будівництвом, а потім, звичайно, ви знаєте, ви починаєте будувати все більші та більші. І ви намагаєтеся побудувати літаки з електроприводом, і я створив такі, але я здебільшого розбивав їх. Тому я не знаю, чи справді це сприяло технічному інтересу, але, звичайно, щось було що мене цікавило протягом тривалого часу, але потім спорт перейшов у старшу школу. І я став більше цікавиться спортом.

Сейверс: Отже, спорт призвів до можливості вступити до Olivet College. І він був великою частиною становлення, чи не так?

Катлер: Я пішов до коледжу Олівет, вони запропонували мені майже повний пакет. Я мав академічну стипендію, і я мав стипендії по баскетболу, бейсболу та футболу. І я б, напевно, не пішов би у коледж, якби я не мав такої пропозиції, тому що ми не могли собі це дозволити. І я подав заявку в кількох інших місцях. Я дуже хотів поїхати в Центральний Мічиган. І вони мене не прийняли. І ця річ з Olivet була дуже вчасною. Це було недалеко від дому. І так я там опинився.

Сейверс: І як ви визначилися з програмою курсу, що вчити в Olivet?

Катлер: Коли я потрапив туди в Olivet, я насправді не знав, я думаю, як і більшість студентів, що я насправді хочу вивчати. Я не знаю, чому я вирішив саме математику, крім того, що це була дуже цікава, складна річ. І потім, коли я вирішив, що математика — це моя спеціальність, для мене було природно сказати: «Ну, я повинен взяти багато фізики", тому я багато вивчав фізику. І мені дуже подобалися математика та фізика. Мені не подобалися деякі інші речі. Olivet — це гуманітарна школа, тому було багато вимог до гуманітарних наук. Це також релігійно пов’язана школа, хоча насправді не дуже релігійно пов’язана, але там було багато речей, які я маю вивчати і це було пов'язано з релігією. Але я якось тяжів до математики та фізики, і це спрацювало добре. Це було чудово.

Сейверс: Отже, ви вчилися в коледжі й думали про те, що буде далі, про те, яку обрати кар’єру, куди ви можете піти працювати. До речі, чи були якісь заробітки під час коледжу?

Катлер: Чи мав я якусь роботу під час навчання в коледжі? Відповідь: Ні. Я був дуже зайнятий спортом, а пізніше, перші два роки коледжу я займався переважно спортом. І вчився рівно стільки, скільки було потрібно, щоб зберегти свою академічну стипендію. А потім останні два роки я дійсно, можна сказати, прикладався до себе і намагався бути старанним учнем. Те, що сталося зі мною, відбулося протягом 18 місяців, коли мені прооперували праве коліно, і витягли медіальний меніск. Я зламав ліву ногу, а потім мені прооперували ліву ногу, і там витягли медіальний меніск. Тож у останні два роки навчання я майже закінчив зі спортом. І протягом цих двох років, я думаю, що я головним чином думав про... Я ніколи не думав, що це буде наприкінці, що я збирався робити... Я думав: "Ну, я просто буду займатися спортом назавжди". І потім після двох років це щось на зразок: «Ну, я не буду займатися спортом вічно. Що я насправді хочу робити? І я не впевнений, чим я насправді хотів займатися, але я думаю, що мені дуже подобалася математика, фізика, і я практична людина, яка любить щось створювати. Тому я дійсно думаю, що я хотів би мати щось на зразок інженерної роботи десь." Тож я начебто націлювався на інженерну роботу, але не збирався йти до інженерної школи в ту епоху, коли таке могло статися. Сьогодні це було б мабуть, дуже важко, щоб хтось міг це зробити. Я маю на увазі, якби у вас був диплом з математики, напевно ви не пішли би на роботу інженера-механіка чи щось подібне. Звичайно, ви можете зробити крок у комп'ютерної інженерії. Комп’ютерні інженери – багато різних дисциплін роблять хороших комп’ютерних інженерів. Так чи інакше, моєю метою в останні кілька років було отримати диплом і знайти роботу інженера.

Сейверс: І як це було? Ви почали проходити співбесіди в компаніях? Компанії приходили до кампусу?

Катлер: У ті часи компанії не приходили в кампуси. Ми говоримо про 1965 рік або принаймні вони не прийшли до нашого кампусу. І в основному я звертався до багатьох різних компаній. Я звернувся до Lockheed, аерокосмічних компаній, я звернувся до General Motors і DuPont. Я не знаю як так трапилося, що я звернувся до DuPont. Побачив десь оголошення напевно, чи що, і чекав, поки люди повернуться і скажуть: «Гей, ми хочемо запросити тебе на співбесіду». Вийшло так, що я фактично мав три серйозних запрошення на роботу. Один був від Chrysler у заводі з м’якої обробки, а це дверні панелі, і м’яка обробка в автомобілі – це в основному всередині. Це була якась дослідницька робота в місті, яке було не надто далеко від місця мого проживання. У мене була тверда пропозиція від Oldsmobile працювати у відділі комп’ютерної бухгалтерії. І я отримав пропозицію від DuPont працювати там на такій посаді нібито це була інженерна робота. Тому я вирішив, що не хочу працювати в Oldsmobile, тому що я не хотів бухгалтерської роботи. Я тоді нічого не знав про компʼютерні науки. Навколо були комп’ютери, і люди використовували їх для ведення записів і бухгалтерського обліку. І, звичайно, були люди в університетах, які використовували їх для інших речей. Але переважно, коли ви говорите про комп’ютерів, широкі знання про комп’ютери полягали в бухгалтерському обліку та діловодстві. І машини IBM робили в основному облік і бухгалтерію. Тому я вирішив, що не хочу там працювати. Тому я вирішив поїхати до Вілмінгтона, штат Делавер, і влаштуватися на роботу в DuPont.

Сейверс: І чи була ця робота такою, якою ви очікували?

Катлер: Чи була робота такою, якою я очікував? Ні. Це був урок на все життя, як проходити співбесіди. І це коли ти на співбесіді, і ви вирішили, що вам подобається працювати в компанії, ви дійсно повинні зрозуміти що ви збираєтеся робити, коли потрапите туди, тому що якщо ви цього не зробите, ви, можливо, не будете цього робити. І я думав, що піду працювати інженером. Трохи невизначено, але все закінчилося тим що, коли я прийшов туди нa роботу, то я займався технічною документацією, написанням стандартних методів тестування для відділу еластомерних матеріалів DuPont, і це були в основному методи того, як ви розтягуєте, тягнете або підкидуєте синтетичний каучук.

Сейверс: Це досить далеко від комп’ютерів. Яким був перший крок до комп’ютерів?

Катлер: Мій перший крок до обчислювальної техніки був з групою в тій самій лабораторії, де я працював, а це була відділ продажів Service Lab, яка допомагала клієнтам DuPont застосовувати продукцію DuPont до своїх продуктів. Дюпон в основному виготовлені сировинні матеріали для використання іншими людьми при розробці продукту. Наприклад, відділ еластомерних матеріалів виготовив неопрен. І неопрен використовувався в багатьох речах, таких як гідрокостюми, і навіть в шинах протягом тривалого часу. Тож там була ще одна група, яка була групою математики та статистики, і я б брав у них інтерв’ю, і вони зацікавилися мною. І приблизно через рік вони запитали, чи можу я бути позичив цій групі на короткий проміжок часу для розробки моделі пінного процесу для компанії Scott Paper.

Сейверс: Гаразд, ми говорили про процес виготовлення піни в DuPont і деякі труднощі в цьому що привело до комп’ютерної кар’єри.

Катлер: DuPont намагався допомогти компанії Scott Paper із новим процесом, який вони розробили для виготовлення піни для швейної промисловості. І хлопець із лабораторії, лабораторії DuPont, яка була менеджером Math and Stat Group хотіла створити модель, яка б допомогла їм спланувати виробництво цього нового машина. І тому вони запитали, чи можу я зробити цю модель. І я сказав, що так, я б це зробив, тому що мені було дуже нудно до сліз намагався написати ці методи тестування, що нікому не сподобалося те, що я писав. Так вони мене послали до школи з IBM, щоб вивчити мову під назвою GPSS-3. GPSS-3 був General System Simulator 3.

Сейверс: Симулятор системи загального призначення.

Катлер: Так, General Purpose System Simulator 3, це їх третя версія. GPSS – це мова це керована подіями блочно-орієнтована мова, де у вас є кілька різних блоків, або ви можете дивіться на них як на функції, які виконують певний вид речей. Як створити транзакцію був блок. Так ви можете створювати транзакції в системі, яку ви намагаєтеся імітувати.

Сейверс: І вони теж працювали паралельно, так? Це була мова з підтримка паралельних обчислень, якщо я пам’ятаю правильно.

Катлер: Так, це так. Мова намагалася імітувати процес реального часу, систему реального часу. І потім все працювало паралельно, але не було потреби в синхронізації. Тож вас вилучила з аспектів синхронізації побудови цієї моделі. І в кінцевому підсумку я побудував досить велику модель, і на етапі побудови моделі я дійсно зацікавився тим, як працює комп’ютер ніж як працювала модель. Тож я почав багато розбиратися в архітектурі комп’ютера, на якому я працював. Машина, на якій ми запускали цю модель, була IBM 4044-- 70-- так, це 44--4044.

Сейверс: Можливо 7044?

Катлер: Це був попередник 7094. Отже, це був 7044. Ось що це було.

Сейверс: Так, 7044.

Катлер: Це була 36-розрядна машина. І це був час, коли я дійсно дізнався, наскільки люди можуть помилятися. І ми навчилися багато скромності щодо програмування та того факту, що комп’ютери роблять лише те, що ви говорите, а не те, що ви маєте на увазі. І я пішов до центру обробки даних IBM. Нам довелося поїхати до Філадельфії, щоб відвідати центр обробки даних IBM, і з моєю колодою з 2000 карток з усі часом, вільним часом, запланованого з представником IBM, моїм босом і всіма іншими. І ми весело піднімаємося туди, і ми збираємося запустити цю модель. І ми досягли цього, і ми витратили весь час на те, щоб усунути синтаксичні помилки з програми, і ми їх так і не усунули в перший день. Тож це був справді принизливий досвід.

Сейверс: Отже, проект GPSS нарешті запрацював, і ви представили модель.

Катлер: Проект GPSS тривав, я думаю, близько року. І з нами було доручено працювати комусь із Scott Paper, який насправді був схожим на мене, мало досвіду і молодий хлопець. І ми з ним підіймемо до Центру обробки даних і запустимо цю модель. І ми вводили в нього інформацію та намагалися отримати результати, і те, що ми намагалися зробити, це те, що ми намагалися зрозуміти, як або який найкращий графік для планування кількох різних кольорів і текстур піни на цьому щоб отримати найкращу продуктивність машини. І врешті-решт ми змусили модель працювати, і ми сказали: «Добре, дайте нам питання, щоб задати моделі», і вони придумали питання про планування, і ми його запустили. У нас була велика презентація, ми передали їм модель і сказали: «Добре, ось модель.

Сейверс: Отже, цей початковий набіг на комп’ютери веде до глибшого вивчення того, як насправді працюють комп’ютери та операційні системи.

Катлер: Після цього проекту я більше зацікавився комп’ютером і вирішив, що справді хотів би залишитися в Math and Stat Group.. Тож я залишився в Math and Stat Group і працював над різними речами. У нас був 1108-й. Ну, спочатку це був 1107-й, машина Univac на експериментальній станції, яка була, я не знаю, за 15-20 миль звідси, і був шатл, який курсував туди-сюди щодня, і ми могли б надіслати програми для запуску на цьому комп’ютері та отримати результати. Тож я почав робити деякі з цих речей для Math and Stat Group, а також брав участь у закупівлі CDC-1700, який був 16-розрядною машиною, щоб автоматизувати машини Instron, які були машиною для випробування міцності на розрив, для лабораторії. І тому я дуже зацікавився цим. Це все тривало, я б сказав, може, близько двох років, а потім я почав думати про те, що я справді хотів бути десь, де я б більше працював на комп’ютерах, а не працював на комп’ютерах як інструменті для вирішення інших проблем. Тож мені вдалося домовитися про переведення в інженерний відділ DuPont, який мав багато обчислювальних можливостей, і саме вони мали 1107-й, який вони оновили до 1108-го. І я приєднався до групи онлайнових систем там.

Сейверс: Отже, 1108 і 1107 мали продукт під назвою Exec 2, який, як відомо, був нестабільним. <сміється>

Катлер: Ну, що я робив у групі онлайн-систем? По суті, я намагався допомогти відділу інженерних послуг, до складу якого входила група онлайнових систем, намагався допомогти операційним відділам, експлуатаційним заводам у відділі еластомерів – фактично з інженерним відділом, це вся компанія. Таким чином, було 13 операційних відділів. Тож вони намагаються допомогти їм із їхніми потребами в комп’ютерному контролі процесів у компанії. Але було багато простоїв, тому що ми були проектно-орієнтовані, і ми намагаємося вийти і продати комусь свої послуги. Тому було багато часу, коли не було чим зайнятися. Тож мене зацікавили моделі 1107 і 1108, я пішов до групи системного програмування й запитав їх, чи можу я чимось для них допомогти. І вони сказали, ну так, Можливо, я міг би допомогти їм з’ясувати, чому Exec 2, яка була операційною системою для 1108, так часто виходила з ладу. Тож вони сказали: «Ми хочемо, щоб ви це з’ясували. І кожного разу, коли 1108 виходить з ладу, ми робимо дамп. А дамп становить приблизно чотири дюйми паперу, складеного віялом, що, я думаю, вісімковий дамп. І ми хочемо, щоб ви з’ясували, чому або що не так із системою». Тож інколи я мав у своєму офісі стос цих смітників заввишки шість футів. І дивлячись на них, намагаючись з’ясувати, що це за законом. І я знайшов кілька проблем, які були нашою виною. Ми винні в тому, що DuPont, тому що ми зробили, я б сказав, близько 2000 рядків модифікацій Exec 2. Але я ніколи не зрозумів, що насправді не так. І я вважаю, що цікава побічна історія полягає в тому, що пізніше, коли я працював у Microsoft на початку 80-х – або, припускаю, на початку 90-х, хтось із Вашингтонського університету в Сент-Луїсі провів дослідження щодо часу появи 1108, і дійшов висновку, що він ставатиме метастабільним кожні чотири години через синхронізатори, а система не синхронізувала всі годинники належним чином. Тож я вважаю, що це була справжня відповідь на те, чому це було так неточно.

Сейверс: Отже, це своєрідне занурення у вогонь у те, що таке операційна система.

Катлер: Це... дозвольте мені сказати, що це було випробування вогнем. Я був наприкінці спроби зрозуміти, чому щось не працює, що змусило мене зрозуміти, як це працює. правильно? Тож мені довелося зрозуміти, як це працює, щоб з’ясувати, чому це не працює. І я був би в цих смітниках, і я б відстежив назад у смітнику, знаєте, можливо, 1000 інструкцій, і тоді слід просто би псувався! Це пішло. Просто зникло. Тож зрештою вони дійшли до того, що мені довіряли настільки, що я фактично став одним із головних людей, які обслуговували систему та вдосконалювали її – те, що ми вважали вдосконаленнями. І внесіть у DuPont спеціальні зміни, щоб оптимізувати роботу 1108.

Сейверс: Отже, це було: «Тепер я дещо знаю про операційні системи і хочу продовжити свою кар’єру в цьому напрямку»?

Катлер: Операційні системи мене дійсно зацікавили. І я не знаю, чому я так вирішив, хлопче, це був той шлях, яким я хотів йти, але це був той шлях, яким я хотів йти. І, можливо, я не знав цього точно в той момент, але я впевнений, що найбільше задоволення я провів на 1108. А потім я... онлайн системна частина цього фактично запрацювала в один момент або кілька моментів, де ми справді мали великі завдання. Ми отримали велику роботу на Експериментальній станції, яка була головним дослідницьким центром DuPont, а це досить велике місце. Це було 120 акрів, і всі 13 операційних відділів мали там офіси. Тому вони вирішили, що хочуть автоматизувати аналіз деяких своїх приладів. Їх приладові дані. Для цього ми запропонували систему Dual-PDP-10. Ми провели, я не знаю, можливо, шість місяців з різними іншими постачальниками. IBM як постачальник, SDS, якщо ви пам’ятаєте SDS? Оскільки Scientific Data Systems є постачальником, якого ми розглядали, Sigma 5. І ми вирішили, що PDP-10 є найкращою альтернативою. Тож ми створили або купили PDP-10, систему Dual-PDP-10 зі спільною пам’яттю, спеціальні, створені компанією Computer Special Systems у DuPont – чи не DuPont – Digital. А потім ми написали операційну систему для одного з них, яка насправді була інтерфейсом. І він вніс усі дані, а потім, коли дані були готові, він передав їх через спільну пам’ять безпосередньо в систему Tops-10, яка потім виконала аналіз програм, написаних на Fortran. А потім ми відправили результати назад. Тому я отримав досить великий досвід роботи з DEC PDP-10. Став досить обізнаним про TOPS-10, і пішов у Digital до школи з TOPS-10, якою керував Дейв Пламбер, який був хлопцем номер один у Digital щодо проведення курсів з TOPS-10. Тож після цього я повернувся до інженерного відділу, і вони дали мені іншу роботу, яка стосувалася обладнання DEC, тобто системи контролю калібру PDP-11 для плівки Chronar, яка використовувалася в магнітній стрічці. І ця система була PDP-11/20, і на той час не було відповідної операційної системи від Digital – чи не Digital – так, Digital. Немає відповідної операційної системи від Digital, яка могла б це зробити. Ми збиралися зробити це на дуже маленькому PDP-11. Я думаю, що він мав лише 8 КБ пам’яті. Тож мені поставили завдання розробити невелику систему виконання в реальному часі, щоб створити систему керування вимірювальними приладами Chronar. Тому, коли я закінчив це, я вирішив, що, можливо, мені пора рухатися далі і думати про щось інше. Насправді я думав про те, що я перейшов від використання комп’ютерів для вирішення проблем до фактичної роботи на самих комп’ютерах, але не в комп’ютерній компанії. І я подумав: добре, якщо я справді хочу максимізувати свою цінність для компанії, і я хочу бути в бізнесі операційних систем, тоді мені слід піти до компанії, яка створює комп’ютери. Тож я домовився про інтерв’ю з Digital у Мейнарді, штат Массачусетс, і ось, вони найняли мене! Тож я пішов до Digital.

Сейверс: Щоб повернутися трохи назад, що ви думаєте про DuPont?

Катлер: Я працював у DuPont сім років. І культура DuPont була для мене справді дуже чужою, тому що це була дуже... це була стара компанія. DuPont було засновано, я думаю, в середині 1800-х років. Вони постачали чорний порох під час громадянської війни. Ось як вони почали з чорного пороху. Дуже бюрократична компанія. Дуже регламентована. Ви не були схильні робити такі речі, як піти поговорити з начальником свого боса. Так воно і було, я добре провів час у DuPont. І це було чудово для моєї кар’єри. Але я почувався там не так комфортно, як у DEC, яка була зовсім іншою компанією.

Сейверс: Чи було у вас уявлення про культуру DEC, коли ви вирішили, що настав час туди переїхати?

Катлер: Коли я пішов у DEC, я абсолютно не уявляв, що таке культура, крім того факту, що я ходив на курс програмування PDP-10, тому я трохи звик до умов. Digital був у млині, і млин був старий. Це також тягнеться з середини 1800-х років. Але насправді нічого про культуру. І я дійсно ніколи не думав про це. Мені здається, я більше думав про цю можливість, ніж про Чи культура буде такою ж чи іншою?" Знаєте, якби культура була такою ж, як у DuPont, я б усе одно пішов, тому що можливість була краща.

Сейверс: Тож поговорим трохи про початок роботи в DEC. Хто був твоїм першим начальником і в якому напрямку стояла задача?

Катлер: Давайте трохи згадаємо про те, для чого мене найняли в Digital. Можливо, це був ще один випадок того, що ви не знаєте, над чим саме ви зрештою будете працювати. Хоча я дійсно мав цей зв’язок, і я збирався працювати над чимось під назвою OS-45. А OS-45 була мрією Дейва Стоуна, який очолював відділ програмування в Digital. А PDP 11/45 мав спеціальну твердотільну пам’ять, яку можна було придбати, тобто пам’ять на 300 наносекунд. І це в 1971 році. А PDP-10 був у той час, я вважаю, що найкращий PDP-10 був вище мікросекундної машини. Тож це була дуже швидка машина. У Дейва Стоуна було таке бачення, що ми збираємося відтворити TOPS-10 на 11/45, і ми також збираємося включити можливості реального часу та пакетні можливості на додаток до розподілу часу. Була зібрана група людей, імовірно, близько восьми осіб, і лідером групи та моїм першим начальником був Пітер ван Рукенс. Пітер прийшов з RCA і відповідав за розробку VMOS... VMOS? Це була операційна система віртуальної пам’яті, яка працювала на RCA IBM-сумісних машинах. І ось я прийшов у Digital, і перші два чи три місяці я витратив, напевно, на роздуми про всі ці речі. І група думала про все це. А потім раптом ми не досягли значного прогресу в цьому, тому що була одна невелика проблема, яку Дейв Стоун не врахував настільки, наскільки мав би, а саме: адресний простір PDP-11 становив 65 Кбайт. І 65 Кбайт просто не вистачало. І можливості керування пам’яттю також не були такими чудовими. Тож нам було дуже важко розпочати роботу та прискорити те, що ми збираємось робити з цією OS-45. Отже, був ще один проект, який відбувався в The Industrial Products Group. Розробити систему управління процесом або ОС управління процесом для PDP-11. Він отримав назву RSX-11C. І вони працювали над цим кілька років, і це нікуди не привело, і вони запитали мене, чи піду я працювати над цим. І я сказав: «Звичайно, мабуть, я попрацюю над цим. Ви знаєте, ми не робимо багато над цим іншим проектом», тож першим проектом, над яким ми працювали, був RSX-11C. система. Тож нам було дуже важко розпочати роботу та прискорити те, що ми збираємось робити з цією OS-45.

Сейверс: І після RSX-11 був C, потім D, потім M, або щось подібне, якщо я правильно пам’ятаю.

Катлер:RSX-11C була першою в серії систем RSX, які в основному спонсорувалися Industrial Products Group, але також були спонсоровані Laboratory Data Products Group, оскільки вони були в бізнесі реального часу, і RSX-11C була лише основною системою, яка підтримувала кілька периферійних пристроїв, перетворювачів A в D, інтерфейси терміналів. Це було приблизно все. Тому виникла реальна потреба в більш функціональних системах. І коли ми заповнювали лінійку PDP-11, звичайно, 11/45 була досить великою машиною, але ми доповнювали її багатьма іншими, 11/40 і 11/70.

Існувала потреба в додаткових можливостях операційної системи, яка підтримувала б більш багате програмування та можливості. Так було кілька систем RSX. Був RSX-11C. Був RSX-11B, про який, можливо, ніхто ніколи не знав. Але в основному це був RSX-11C, який міг завантажувати файли DOS 11 з диска. Так воно і було – ми можемо запускати програми на диску та запускати їх, але це все ще система лише з ядром. А потім RSX-11M, і RSX-11D. Порядок, у якому ми це робили, був RSX-11C спочатку, а потім B. І коли я зробив B, я сказав: «Я зроблю B, але я хочу, щоб ви пообіцяли мені, що мені більше не доведеться над цим працювати». І вони сказали: "Добре". Тож приблизно в той самий час запускався RSX-11D, який був еквівалентом RSX-15, яка була 18-розрядною системою реального часу, яку продавав Digital. І тому мені доручили працювати над цим. І був хлопець на ім’я Хенк Країчі, який був головним дизайнером цього, тому що він працював над RSX-15. І я погодився зробити для нього компонувальник накладання. Отже, моя участь у RSX-11D полягала в компонувальнику оверлеїв. І коли ми закінчили, це вийшло трохи більше, ніж ми сподівалися, і трохи повільніше, ніж ми сподівалися. Тож у мене виникла ідея створити систему з дійсно іншою архітектурою. RSX-11D мав архітектуру, де в основному все працювало як процес. І це означало, що драйвери запускалися як процеси, що означало, що між програмою, яка потребувала обслуговування драйвера, і драйвером мав існувати механізм IPC, міжпроцесного зв’язку. Що насправді не сприяло продуктивності в реальному часі, яку ми хотіли мати. Тож у мене була інша ідея створити систему, яка була б значно іншою. Фактично, це здебільшого схоже на інші системи, які ми створили або я брав участь у роботі. Тому я запропонував створити RSX-11M. І Industrial Products Group дуже захопилася цим. І вони дали мені, я думаю, близько восьми людей для роботи над цим. І ми завершили це приблизно за півтора-два роки. І це стало основною системою реального часу для PDP-11, оскільки вона працюватиме на всіх PDP-11. Ті, що мали систему керування пам’яттю або блоки керування пам’яттю, і ті, які цього не зробили. Насправді він працював на системах від 32 Кбайт до 2 мегабайт, великий діапазон.

Сейверс: Отже, це був перший раз, коли ви запускаєте великий програмний проект? Великий проект розробки операційної системи?

Катлер: Це був перший раз, коли я керував великим проектом? Напевно, ви б вважали це першим великим проектом, тому що це було те, що ми насправді збиралися продавати. Ми збираємося продати RSX-11M. У нас будуть клієнти, у нас будуть проблеми з підтримкою, і все це є. І нам потрібно буде підготувати документацію. Система PDP-10, напевно, була не таким великим проектом, але я також буд головним відповідальним за нього. Дуже недосвідчений. Я не знаю, як DuPont довірив мені, щоб зробити це, але вони зробили, і я вдячний їм. Таким чином, RSX-11M був справді першим, коли я зробив проект. І тому я розробив навколо RSX-11 багато речей про те, як ми збираємося це зробити, і що ми збираємося робити, і що ми маємо робити. І тому одна з перших речей, яку я хотів знати, це: "Який обсяг роботи? Що ми збираємося робити?" Ви не можете просто сказати, що ми створимо операційну систему. Ми повинні знати: «Ну, які можливості він матиме? Які його обмеження?» Одним із обмежень було те, що він мав бути сумісним із RSX-11D. Тож це був не чистий аркуш паперу, на якому ми могли просто піти й створити нову систему. Це було, добре, воно має бути сумісним з підмножиною, але воно сумісне на рівні коду, а не на бінарном рівні. Тож це було велике застереження, тому що бінарної сумісності досягти набагато важче. Отже, RSX-11M була моєю першою справжньою операційною системою з нуля. Думаю, на це пішло близько двох років. Він був доставлений із, як мені здається, досить гарною якістю для інструментів і всього, що у нас було на той час. Моя філософія щодо якості полягала в тому, що якість повинна бути на першому місці. Для мене все ще найголовніше, що якість — на першому місці.

Сейверс: Отже, гумовий штамп «Розмір — це мета» взяв участь у цьому?

Катлер: Одним із великих обмежень із RSX-11M було або однією з великих проблем із RSX-11D було те, що він вимагав дуже багато пам’яті. Тож із RSX-11M ми хотіли створити набагато меншу систему, і я це зрозумів.

Відразу з’ясувалося, що єдиний спосіб зробити це — ми дати кожному бюджет. Тож у кожного був бюджет щодо обсягу пам’яті, який вони могли використовувати. І це була їх мета. Отже, якби хтось повернувся і сказав: «Я ніяк не можу цього зробити, і яким би не був бюджет, ми б переосмислили це. Але загалом усі виконали свій бюджет. І тому, щоб підкріпити це, кожен... у мене був цей штамп із написом: «Розмір — це ціль». І на всьому було написано «Розмір — це ціль». Знаєте, у ті часи не було електронної пошти. Тож не було електронного обміну повідомленнями, тому весь зв’язок відбувався через пам’ятки, і на кожній нотатці було написано «Розмір — це ціль». «Розмір — це ціль». Таким чином ми отримали 32 Кбайтну систему, для операційної системи було 16 Кбайт, і 16 Кбайт для будь-якого середовища користувача. Або середовище програми. Режиму користувача насправді не було. Був режим користувача та режим ядра, але це були спеціальні системи. Це не була система, де було багато людей, які збиралися використовувати це в загальному вигляді. Це було таке: «Ця система призначена для керування чимось у режимі реального часу». І той, хто купив систему, напише програмне забезпечення, яке контролюватиме їхній процес.

Сейверс: Ось де з’являється перше ядро ​​Dave Cutler, DCK? Ви самостійно кодуєте значну частину операційної системи?

Катлер: Що ж, усі речі, над якими я працював, я багато зробив сам. Я зробив… повертаючись до PDP-10, я зробив багато з цього сам. Фактично, все, що я робив протягом своєї кар'єри, я завжди був дуже практичною людиною. Я не можу просто стояти осторонь і сказати: «Ви знаєте, це те, що ми збираємося побудувати, ви, хлопці, підіть і напишіть специфікації, а я буду керувати вами». Я ніби стаю частиною команди і дивлюся на себе більше як на лідера, ніж на менеджера. І я хочу вести людей до створення продукту, а це означає, що я є частиною цього. І немає такої роботи, яку я не можу... яку б я не виконував. Мені подобається... У мене є таке маленьке прислів’я: «Успішні люди у світі — це люди, які роблять те, чого невдалі не роблять». Тому я завжди був цією людиною, Ви знаєте, я буду будувати систему, я буду виправляти помилки, я буду виправляти помилки інших людей, я буду виправляти збої в збірці. Усе це є частиною виконання роботи.

Сейверс: Отже, у PDP-11 закінчився газ. DEC вирішує, що настав час створити 32-розрядний комп’ютер. Вони позаду, SDS, SEL та інші мають 32-розрядні версії, і потрібна нова операційна система, і проект VMS починається.

Катлер: Приблизно, я думаю, це був 1975 рік, Digital зрозумів, що їм потрібно створити 32-розрядний комп’ютер. І тому, будучи частиною RSX-11M і світу 11, я взяв участь у цьому. У нас було кілька архітектурних груп, кілька рівнів архітектурної групи. Ми вирішили назвати це VAX, і VAX була кодовою назвою, яка розшифровувалась як Virtual Address Extension, оскільки PDP-11 мав такий малий віртуальний адресний простір. За цим стояв Гордон Белл. Це було його бачення, що ми повинні створити цей комп’ютер. VAX-A була групою апаратної архітектури, а VAX-B була свого роду групою перевірки. А потім, я думаю, був ще один під назвою VAX-C, який був рештою компанії. І я був ніби формальним членом VAX-B, але також і неформальним членом VAX-A. Тож я провів багато часу в групі VAX-A, обговорюючи комп’ютер та інше. До цього були причетні Білл Стрекер і Гордон Белл. Це було моє перше справжнє спілкування з Гордоном. Він був у компанії весь час, поки я був там, але це був перший раз, коли я справді мав з ним справу. І ми зустрічалися майже щодня і говорили про цей комп’ютер, про набір інструкцій і про те, що нам робити. І одна з найбільших цілей VAX полягала в тому, щоб мати можливість закодувати програму в тому самому обсязі пам’яті, який міг закодувати PDP-11. Тож це диктовало інструкції. Інша справа: ми точно хотіли трохи збільшити віртуальний адресний простір. І створення 32-розрядного комп’ютера дозволило б нам це зробити, і в той час перехід від 16 до 32 був таким: «Чоловіче, як у нас може закінчитися 32 біти адресного простору». Пізніше ми перейдемо вперед і з’ясуємо, чому нам не вистачило 32 бітів. Отже, VAX-A та архітектурна група, в основному, визначали архітектуру. І були задіяні інші люди з програмного забезпечення. Були залучені деякі люди з групи PDP-10. В основному Пітер Конклін, і ми найняли колегу з Xerox, який працював у SDS, який працював над системою під назвою CP-5, яка була однією з систем, які працювали на Sigma 5. Це була операційна система Sigma 5. Його звали Дік Хустведт. Дік був залучений до VAX-A, а інша особа була залучена до Пітера Ліпмана. І деякі інші люди. Але в основному ми розробили архітектуру, а потім компанія сказала: «Ну, давайте побудуємо». І тому ми сказали: "Ну, як довго ви хочете, щоб це тривало?" І вони сказали: «Ну, два роки здається розумним». І він сказав: «О, мій пане, ми ніколи не зможемо побудувати це за два роки, це надто складна архітектура, щоб побудувати її за два роки». Тож ми зʼїздили на оффсайт, один тиждень, прийшли на зустріч Ісуса про те, що ми будемо робити з архітектурою, щоб цю систему можна було побудувати за два роки, і це – я думаю, це називалося комітетом Блакитної стрічки, і було три люди, які займаються розробкою програмного забезпечення: три розробники програмного забезпечення та три розробники апаратного забезпечення, а також деякі архітектори. І ми розробили остаточну архітектуру VAX, яка трохи зменшила складність архітектури набору інструкцій. Я підозрюю, що люди все ще скажуть, що архітектура набору інструкцій була надто складною, але до цього вона була справді складною. І інше, що сталося, це те, що управління пам’яттю було настільки складним, що єдиною людиною, яка могла це пояснити, був Річі Ларі. А всі інші сказали: «Так, здається, це може спрацювати, але ми не зовсім впевнені». І тому ми справді спростили архітектуру керування, щоб архітектори апаратного забезпечення подумали, що вони можуть створити її ефективно, а люди, які займаються програмним забезпеченням, подумали, що ми можемо створити для неї операційну систему. І одне з рішень, які ми прийняли з VAX – насправді ми прийняли кілька рішень з VAX, які обмежили термін служби VAX. Одним з них було кодування потоку інструкцій, еквівалентне PDP-11, що спричинило надзвичайно складну реалізацію апаратної системи, яка була в основному в апаратному забезпеченні, а не в основному в мікрокоді. Отже, набір інструкцій VAX здебільшого виконувався в мікрокоді, а не в апаратному забезпеченні, тому що його було дуже важко декодувати. І інше, що було свого роду помилкою, довгостроковою помилкою, полягало в тому, що розмір сторінки становив 512 байтів, а щось більш розумне, наприклад 1 Кбайт або 4 Кбайт, було б набагато кращим рішенням. Однак ми подивилися на це, і спеціалісти з маркетингу хотіли продавати системи VAX розміром з пам’яттю систем PDP-11. Тому вони хотіли продати систему, яка мала 128 Кбайт. Добре, найскладнішою інструкцією в архітектурі VAX була «додати пакет шість». Це була упакована інструкція додавання, десяткова інструкція з шістьма операндами. Це може торкнутися 40 сторінок. Так сталося, якщо потрібно торкнутися 40 сторінок, а у вас є лише 128 Кбайт, тоді ви не хочете потрапити в ситуацію блокування в реальному часі, коли те, що відбувається в системі, є таким, що ви ніколи не зможете отримати всі сторінки щоб фактично виконати інструкцію. Тому ми зупинилися на наборі інструкцій розміром 512 байт. Тож після того, як архітектура була підписана, і ми вирішили, що там багато заповнення, ми пройшли через комітет блакитної стрічки. Опублікував остаточну архітектурну специфікацію, потім ми зібрали групу програмного забезпечення та групу апаратного забезпечення для створення апаратного забезпечення та створення програмного забезпечення, і я був технічним керівником групи програмного забезпечення. А потім ми витратили, я б сказав, шість місяців, намагаючись подумати і зрозуміти, як побудувати систему, тому що ми смертельно боялися побудови пейджингової системи. У той час не було великого досвіду роботи з пейджинговими системами. У PDP-10 не було пейджінгу, у нього був свопінг. Компанія BB&N побудувала модифікацію PDP-10, яка мала пейджинг. Але це працювало не дуже. Multix була системою підкачки, ія не впевнений що Multix добре працюватиме на сучасному обладнанні. Це була чудова система, вона породила багато творчих ідей, але в основному була дуже повільною. Будь-хто, хто працював на цій системі, точно не турбувався про продуктивність. Тож ми витратили довгий час, щоб з’ясувати, як побудувати цю систему, тому ми думали, що матимемо гарну продуктивність, ми зможемо створити її за пару років. І ми мали б якість, яку хотіли мати. І ось через шість місяців ми створили документ, який назвав його, я думаю, План дизайну та проекту Scarlet. Або це був план проекту Скарлет. І з цього ми почали, і ми впровадили – або насправді ми розробили VMS переважно на RSX-11M. На той час у RSX-11M була невелика можливість розподілу часу, тому було багаторазове використання, і ми мали великий 11/70. Ймовірно, на ньому два мегабайти пам’яті. Два мегабайти! Тому ми розробляли в основному на RSX-11M, але потім запускали це на симуляторі. Група, яка фактично створила VAX-11/750, була групою, якій було призначено створити емулятор для VAX. І ми фактично запустили емулятор, який є апаратним емулятором. Ми працювали не на симуляторі, ми на емуляторі. І ми розробили це... запустили його там. А потім, коли було доступне апаратне забезпечення або макетна плата для VAX 11/780, ми взяли те, що мали, і піднялися нагору, і воно практично запрацювало. Він завантажився, і принаймні ми дійшли до точки, коли він не вийшов з ладу. Таким чином ми почали, а потім вони створили прототип. Я думаю, що це був Proto 4, і це була наша машина розробки, і всі працювали на машині розробки. І ми керували тим, що побудували. Тому ми розробляли в основному на RSX-11M, але потім запускали це на симуляторі. І це був перший випадок eat your own dog food. Де ви використовуєте те, що розробляєте, і це дає вам великий стимул виправляти все, що не так. – VMS — це система розподілу часу. Тож ми всі були в своїх офісах і всі поряд із машиною, і якби вона вийшла з ладу, ви знаєте, Дік Хустведт і Пітер Ліпман і я вийшли б подивитися, чому вона вийшла з ладу. І ми б з’ясували, чому він вийшов з ладу. І ми перезавантажуємося, повертаємось до нашого офісу та виправляємо проблему. А потім вийдіть і перезавантажте нову систему, і тоді всі будуть з новою системою. Ось так і відбулася розробка VMS. І в день, коли ми відправили VMS, у нас не було жодної відомої помилки. Це було нуль відомих помилок. Це не означало, що помилок не було. Але не було жодної відомої помилки, і я знаю, що була помилка прямо в самому кінці, коли у нас був race condition, яку було виправлено об 11 годині . А потім остаточні бінарні файли були передані на завод-виробник.

Сейверс: Отже, VMS і VAX 11/780 ніби запустили DEC у суперміні, більші додатки, більше підштовхують до комерційного світу, з’являються всілякі нові функції та вимоги, і це породжує значну еволюцію VMS. Отже, ви були з командою VMS для всього цього.

Катлер: Ні. VMS був моїм першим дуже складним проектом, де на нас були накладені деякі дуже жорсткі обмеження. Два роки, які нам дали для того, щоб врешті-решт або ефективно створити систему рівня та калібру VMS, були дуже короткими. І в той момент я подумав: «Можливо, мені варто спробувати щось інше, що мене цікавить». І одна з речей, яка мене дуже зацікавила, це компілятори. Тож наприкінці VMS Version 1 я вирішив створити групу компіляторів для створення компілятора PL/1. Тож я справді не продовжував продовжувати версії VMS. Тоді я відокремився і створив цю групу, яка складалася, здається, з чотирьох людей. І я думаю, що ми виросли приблизно до шести людей, щоб створити компілятор PL/1, і ми купили інтерфейс для компілятора в компанії в Бостоні. І ми створили бекенд, який був генератором коду. І я думаю, що це був ще один дворічний проект чи близько того. І частина цього проекту також породила C-компілятор для VAX.

Сейверс: І це був приклад того, як насправді eat the dog food, написання компілятора в компіляторі на PL/1?

Катлер: Насправді PL/1, що стосується eat the dog food, був цікавим способом створення компілятора. У нас був інтерфейс компілятора, який був доставлений нам на Multix. І Multix, ми спочатку подумали, що ми візьмемо компілятор Multix і скомпілюємо частини компілятора Multix, і ми перенесемо їх у VAX і запустимо їх, зрештою. Ми спробували запустити його віддалено в системі Multix, але нам не вдалося змусити його працювати в режимі повного блокування циклу. А це як, я не знаю, сто, чи що там, до Бостона п’ятдесят миль. Це 300 бод. Тож ми спробували напівдуплекс. Це був трохи кращий напівдуплекс. Тож ми просто, щоб це теж не спрацювало. Тож ми вирішили найняти трансфер. І хлопець, який працював над інтерфейсом, виробляв щось на Multix, запишіть це на магнітну стрічку, віддайте транспортній службі, принесіть до DEC, і ми знімемо це з магнітної стрічки. Отже, перше, що ми зробили, ми завантажили компілятор назад. Отже, ми робили генератор коду з нашого боку, але генератор коду був здебільшого написаний на асемблері. Тож у нас це спрацювало, а потім ми повертали фази компілятора одну за одною, назад, доки не поверталися до початку компілятора, а потім ми могли скомпілювати все в Digital. Тож ми справді їли собачу їжу, тому що весь компілятор був написаний на PL/1, за винятком тих частин генератора коду, які мали запускатися останніми. Отже, ми робили генератор коду з нашого боку, але генератор коду був здебільшого написаний на асемблері. Тож у нас це спрацювало, а потім ми повертали фази компілятора одну за одною, назад, доки не поверталися до початку компілятора, а потім ми могли скомпілювати все в Digital. Тож ми справді їли собачу їжу, тому що весь компілятор був написаний на PL/1, за винятком тих частин генератора коду, які мали запускатися останніми. Отже, ми робили генератор коду з нашого боку, але генератор коду був здебільшого написаний на асемблері. Тож у нас це спрацювало, а потім ми повертали фази компілятора одну за одною, назад, доки не поверталися до початку компілятора, а потім ми могли скомпілювати все в Digital. Тож ми справді їли собачу їжу, тому що весь компілятор був написаний на PL/1, за винятком тих частин генератора коду, які мали запускатися останніми.

Сейверс: Отже, зараз ми приблизно в 1981 році в DEC чи близько того? Або трохи раніше?

Катлер: Це приблизно, ну, це 1980/81, десь у тому році. Можливо, на початку того року.

Сейверс: Отже, складаються якісь обставини, і ви думаєте: «Мейнард більше не для мене».

Катлер: Тож те, що сталося після компілятора PL/1, полягало в тому, що я справді трохи втомився від зростання Digital. Коли я починав працювати в Digital, там було 12 000 людей, і я не знаю, у 1981 році точно вже не було 12 000. Там було 75 000 чи щось. Тож те, що почало бути справжнім інженерним стартапом, інженерним середовищем, раптом стало більше середовищем управління, маркетингу та керування програмами, чим я не був дуже задоволений. І тому я висловив деякі речі Гордону про те, що, можливо, я хотів би бути в іншому місці. І він запропонував... він сказав: "Ну, куди б ти не хотів піти, ти знаєш, можливо, ми можемо придумати, як ми можемо відкрити там інженерний об'єкт". І я сказав: “Ну, я не знаю. Можливо, мені тут буде добре”.

Тоді з’явилася можливість створити компанію, яка збиралася комерціалізувати компілятор – вибачте, мову, яка фінансувалася урядом для управління в реальному часі, який називався Praxis, і це було зроблено для Lawrence Livermore. І це було фактично зроблено для проекту Shiva Nova, який був проектом термоядерної енергії. Тож я був начебто в захваті від цієї робити. І ми – "ми", я думаю, близько шести людей. Нас троє з DEC і пара від... або четверо з нас з DEC і пара з Lawrence Livermore. Ви знаєте, подорожувати по Силіконовій долині та шукати гроші, і ми дійшли до точки, де, я думаю, ми зрозуміли, що, можливо, це не так правильно, або принаймні я зрозумів, що це було неправильно. І тому я сказав Digital <раніше>, "Я йду." І так, ви знаєте, боги, у нас була визначена кінцева дата закінчення роботи і все таке. А потім все а раптом я думаю: "О, знаєте, я не впевнений, що це вийде, розумієте?" Боже, у нас була дата розірвання і все. А потім раптом я думаю: «О, знаєте, я не впевнений, що це вийде, розумієте?» Президентом компанії мав стати хлопець із проекту Shiva Nova, і його, здавалося, більше цікавило, як він збирається витратити всі наші стартові гроші, які ми самі вклали, на такі речі, як різні кольори та зарплатню для своєї дружині. І раптом усі наші гроші, які ми зібрали разом, зникли. І я думаю: «Ого, я не знаю, чи хочу я піти з цим хлопцем». Тому в останній момент я сказав: «Ні, я не збираюся цього робити». Таким чином, усі інші хлопці з DEC кажуть: «Ну, ми теж цього не робимо». Тож тоді виникло запитання: "Боже, що ти збираєшся робити?" І тому я сказав: «Ну, знаєте, я вважаю, що це дійсно доречно, щоб я подумав про те, щоб бути в іншому місці, де я трохи ізольований від... трохи меншого середовища, де у нас немає всієї бюрократії, яку ми розвиваємо в DEC». Тож Гордон каже: «Ну, боже, як на мене, це звучить добре. Куди б ти хотів піти?» І я сказав: "Ну, Я не можу бути на східному узбережжі, бо цього буде недостатньо далеко. Знаєш, я справді не надто люблю Південний Захід. Тож, можливо,Арізона або Нью-Мексико. Напевно, Техас не найкраще місце. Ймовірно, Західне узбережжя було б найкращим місцем". Ну, каже Гордон, знаєте, "Західне узбережжя було б добре, але я хочу, щоб ти був десь там, де є університет, де є хороша програма, щоб ми могли залучити людей звідти, і, можливо, ми дійсно зможемо співпрацювати з університетом." Тож відділ нерухомості DEC організував цю поїздку, під час якої ми летіли до кількох різних місця на Західному узбережжі та дивились. І ми поїхали в Сан-Франциско, ми поїхали в Сакраменто. Було дуже спекотно на Santa Rosa. Ми поїхали в Портленд і приїхали в Сіетл. І я витратив небагато часу в Портленді, трохи раніше. Фактично, що породило попередню пропозицію Гордона створити Інженерний засіб для мене полягав у тому, що я фактично проходив співбесіду в Intel у Портленді, що є свого роду інтерес – це начебто повернення назад, але поверніться назад і лише на секунду. І це трапилося, і я був на інтерв’ю, і в той час вони створювали 432, який був їхнім 32-розрядним комп’ютером. Що зрештою так і не здійснилося. Але ми втратили пару людей. Дейв Бест, який був програмний менеджер для 11/750 пішов туди. Тож я був на інтерв’ю там, і дійшло до того, що вони збиралися запропонувати мені роботу та казали: «Ну, ми не можемо запропонувати вам роботу, тому що ми дійсно співпрацюємо багато з Digital, і ви повинні сказати Гордону Беллу, що ви зацікавлені в цьому". Тому я сказав: "Е, без проблем”. Я подзвонив Гордону і сказав: «Гордон, я був на співбесіді з Intel. А я їх не дуже хочу роботу, але я хочу почути їх пропозицію, тому що я хочу зрозуміти, скільки я вартий". Я сказав: "Добре. Це нормально для тебе?" А він каже: "Звичайно". Я поклав трубку, і приблизно через 15 хвилин дзвонить телефон, і це Ларрі Адмін Portner. Сказав: «Ларрі та Гордон хотіли б піднятися на Спіт-Брук-роуд у Нью-Гемпширі і пообідати з вами. І я сказав: "О, це добре. Коли?" "Сьогодні, добре?" І я сказав, — Звичайно. Тож вони прийшли до Спит-Брук, ми пішли пообідати, і вони по суті сказали: «Ну, чому ти хочеш піти?" І я сказав: "Ну, я не хочу йти, я просто хотів знати, яка моя вартість на ринку". Вони сказали: "О, ну, може, ми зможемо щось вирішити". Я сказав: «Мені дуже подобається Портленд». І Гордон сказав: «Ну, можливо, ми можемо подумати про це». Отже, знаєте, вони зробили щось із зарплатою, і щось про опціони на акції, і я трохи про це подумав. Тоді я сказав: «Гей, я не дуже хочу зробити це. Я залишуся тут на деякий час", а потім з'явилася інша можливість для компанії. І тоді, коли це пропало, це було справді так: "Я справді хочу переїхати". Так чи інакше, ми повернулися на Західне узбережжя повертаючись на Західне узбережжя, ми їздимо всюди, і ми приїжджаємо в Сіетл, і йде дощ, але все зелене. І тому я сказав: «Ой, хлопче, це справді гарне місце». І ми відвідали університет. ми поспілкувався з завідувачем кафедри інформатики. Я забув, як його звали. Він справді був зацікавлені в тому, щоб ми прийшли. І тому ми повернулися додому, подумали про це деякий час і сказали: «Сіетл має бути тим місцем. Це має бути те місце». Таким чином ми опинилися в Сіетлі. Начебто ми поїхали, подивилися на кілька різних місць і вирішили, що Сакраменто нам не дуже подобається. Район затоки був трохи надто зайнятий для нас. І Bellevue було досить гарне місце бути. Так ось де ми закінчили.

Сейверс: Отже, ви тут. Тож кілька людей вирішили поїхати з вами, а ще деяких людей найняли тут на місці. Ви запустили лабораторію.

Катлер: Ми прийшли сюди і взяли з собою, я думаю, близько восьми людей. І ми найняли... знаєте, одна з речей полягала в тому, що нам сподобалося найняти кількох людей з Університету Вашингтона, щоб зміцнити цей зв'язок з Університетом Вашингтона. Ми найняли звідти пару людей і розпочали проект — наш статут, до речі, передбачав виробництво — знову ж таки, повертаючись до коріння реального часу — створення програмного забезпечення для вбудованих систем VAX на основі мікросхем. У той час ми працювали над набором мікросхем під назвою Scorpio. Що за сьогоднішніми мірками було б величезним, оскільки це було шість мікросхем. Я думаю, що три з них були нестандартними чіпами VSLI. Тож це було велике порівняно з сьогоднішнім днем, але це було дуже мало порівняно з тим, що ми мали в ті часи. Тож наш статут полягав у створенні цієї системи виконання, невеликої операційної системи реального часу, який було дуже легко програмувати. І це було дуже легко для впровадження програм реального часу. І назва системи була VAXELN. І це був мій перший вхід, наш перший вхід у багатопотоковість. Ми фактично зробили багатопотоковість у VAXELN, приблизно в той самий час, коли ядро ​​Mach робило багатопотоковість у Carnegie Mellon, приблизно в той самий час. Отже, ми наполовину завершили цей проект і почали думати: «Ну, Scorpio існує вже досить багато років. Ми не знаємо, коли його буде доставлено. У нас насправді немає відповідної платформи щоб запустити це.

Можливо, нам слід подумати про те, що ми повинні зробити з VAX, щоб, можливо, зробити VAX з меншою архітектурою". Тож ми розпочали роботу в компанії під назвою MicroVAX, яка мала скоротити архітектуру. А пізніше, після того, як ми розробили архітектуру , ми подумали: «Ну, у нас досі немає жодної платформи, на якій це можна було б запустити, тому що нам доведеться виготовити чіп для цього». І був чіп MicroVAX. «Тож, можливо, нам варто створити апаратне забезпечення Група тут також, і ми повинні створити реалізацію MicroVAX, яка не буде одним чіпом, але це буде невелика система, можливо, розміром з PDP-11/05. Тож ми залучили ще кількох людей із DEC-East для проекту обладнання. І це були в основному люди зі Сходу, але ми також найняли, я думаю, трьох людей на місцях, тому що в цій галузі багато чого відбувається з електронікою, тому було легко найняти кількох людей і виготовити MicroVAX-1. Ми фактично відправили VAXELN і MicroVAX-1 разом. У той час я дуже зацікавився апаратним забезпеченням, і закінчив тим, що працював над VAXELN майже над написанням ядра. І інші люди написали фрагменти файлової системи та фрагменти, які йшли навколо неї. Але потім я перейшов на апаратну групу для MicroVAX-1 і написав увесь мікрокод.

Сейверс: І десь по дорозі ви познайомилися з Карвером Мідом і взяли команду навчитися розробляти мікросхеми.

Катлер: Я реалізував систему MicroVAX-1 так, як Гордон подумав, що було б гарною ідеєю спробувати нову технологію щодо виробництва кремнієвих мікросхем. І одна з нових технологій, яку рекламував Карвер Мід, був із Калхтеху?

Сейверс: Калтех, так.

Катлер: І Лін Конвей мала кілька силіконових електроінструментів і компанію, яка була заснована — фактично під назвою Silicon Compilers, у якій Карвер Мід був принципом, а також Джон Хеннесі. І ми зібралися з ними та перевірили чіп, який вони могли б створити, який би був центральним процесором системи, і він був би на одному чіпі. І ось... вони виготовили чіп. Вони розробили чіп разом із нашими специфікаціями, що рухаються вперед і назад. Вони не мали всієї експертизи. А потім наші апаратники розробили все апаратне забезпечення, яке йшло навколо цього. Ми провели жахливий час, створюючи чіп. Для початку ми пішли до компанії під назвою AMI, яка, знаєте, у ті часи напівпровідникові компанії з’являлися як кульбаби, їх було багато. Вони з’являлися, вони залучили венчурний капіталу. Вони б перекинулися і прикинулися мертвими. AMI насправді ніколи не створювала для нас чіп, який би працював. Вони зробили чіп, і ми отримали чіп, ми дивилися на нього, і вони зробили всі маски навпаки. Вони всі були негативними щодо того, якими вони повинні бути.

Сейверс: Ой.

Катлер: Ой! Тому я не знаю, як це сталося. Тому ми звернулися до іншої компанії під назвою SEEQ. І SEEQ фактично виготовив чіп. Я не пам’ятаю, щоб у нас були проблеми з чіпом щодо помилок. Можливо, були деякі речі, над якими ми працювали – я точно не пам’ятаю. Я пам’ятаю, що він був майже без помилок. І ми змогли взяти цей чіп і помістити його в систему на основі Q-Bus. І це був MicroVAX-1, і ми запустили на ньому VAXELN, але пізніше ми також запустили на ньому VMS. Під час обговорення архітектури MicroVAX ми трохи скоротили можливості керування пам’яттю VMS. Не VMS, можливостей керування пам’яттю VAX дуже мало, що означало, що VMS не працюватиме з ним. Для того, щоб система VMS працювала, потрібно було б серйозно модифікувати її. І ось я писав мікрокод і подумав: "Боже, ніж не робити цього, і ми запускаємо VMS. Тож ми запустили VMS майже одночасно з системою. І я точно не пам’ятаю рік, це був, мабуть, 86-й чи щось таке, може, 84-й. Приблизно три роки, можливо, три роки в розробці цієї системи. Тож це був наш перший проект у DEC West.

Сейверс: І куди це привело?

Катлер: Ну, це призвело... до чого це призвело? Це призвело до проблем! <сміється> Це призвело до великих проблем, тому що ось ми тут, тепер у нас є така досвідчена група операційних систем. У нас є досвідчена апаратна група, що тепер робити? І тому проблема полягає в тому, щоб спробувати знайти щось, чим не займається інша група в штаб-квартирі. І тому ми розглянули кілька пропозицій щодо будівельних проектів або системного обладнання, яке було переважно апаратним. У DEC West були люди, які хотіли побудувати робочу станцію. І тоді були люди, які хотіли створити більш продуктивну систему, ніж робоча станція. І в кінцевому підсумку ми не побудували робочу станцію. Зрештою ми спробували побудувати більшу систему, і це призвело до великих проблем, тому що ми як завжди переборщили.

Ми завжди дублювали певну функцію, яка – або якусь частину простору цінової ефективності, якою хтось у головному офісі вже займався. Тому ми пройшли кілька проектів, намагаючись знайти правильний VAX для створення. І, по суті, я б повернувся до Мейнарда і спробував домовитися про те, що ми повинні побудувати, отримати певний внесок і повернутися, і ми працювали шість місяців, а потім Мейнард вирішив, що ж, це було не те, що вони хотіли, щоб ми побудували. Тож нам доведеться знайти щось інше для будівництва. Таким чином, це наштовхнуло нас на думку про те, що RISC ставав дуже популярним у той час, і це дійшло до того, що було багато розголосу про те, що RISC має кращу продуктивність, ніж VAX, і RISC був тим шляхом, і тому ми зацікавилися RISC. І в компанії було кілька RISC-проектів. Такий був у Marlboro. Один відбувався в районі затоки на WRL, яка була Західною дослідницькою лабораторією. І ми ніби працювали над одним. Тож Джек Сміт, який був старшим віце-президентом з розробки, сказав: «DEC West відповідає за архітектуру RISC». Так розпочався проект Prism, який був новою архітектурою RISC для DEC. І я думаю, що ми, ймовірно, почали це приблизно у 85 році, я думаю, можливо? '85? Отже, ось що сталося після того, як ми... ми досягли успіху в цьому, ми просто надзвичайно успішні. Дуже низькі накладні витрати. Дуже мало людей. Ми виконали завдання просто рекордно швидко. За рекордну суму грошей. Інженерні витрати, витрати на NRE були схожі на безцінні порівняно з іншими проектами. Але потім у період неможливості знайти правильну річ, а потім архітектуру. Нову архітектуру.

Сейверс: Отже, я думаю, це була війна RISC, яка почала розвиватися в DEC між різними частинами компанії?

Катлер: Що ж, причиною того, що архітектуру Prism фактично було призначено DEC West, було те, що в компанії було дуже багато проектів, які намагалися розробити архітектури RISC. І, звісно, ​​у Digital вже була... тепер у нас була 36-бітна лінія, яка була PDP-10, а потім DEC System 20. У нас була лінія VAX, у нас була лінія PDP-11. Я не думаю, що ми, мабуть, робили якісь 18-бітні 9 і 15. Можливо, на той час ми все ще відправляли кілька 8-ми. Але нам справді не потрібні були три-чотири нові архітектури. Таким чином, архітектура Prism починалася так само, як і архітектура VAX, з представниками... У VMS був представник. Гудзон, який був галуззю напівпровідників, мав свого представника. У Marlboro був представник. Там був один із хлопців, які працювали над цією архітектурою. Ми мали себе, а потім у нас був хлопець з групи архітектури. Потім ми витратили наступні три роки, приблизно три роки, переглядаючи це, а потім повертаючи це до старшої технічної спільноти. І вони дивилися на це і казали: «О, нам це не подобається». І ми б повернулися. Ми перевернули від 64 до 32 до 64 назад до 32 в архітектурі, і знадобилося багато часу, щоб все це відсортувати, і тоді весь принцип RISC полягав у створенні системної архітектури, яку було легко реалізувати. Вам не потрібно було використовувати методи грубої сили. І масивні пакети перевірки. Але потім компанія якось збилася з курсу і почала додавати всі ці речі. Перше, що сталося, це те, що нам знадобиться векторна арифметика. Тож нам доведеться конкурувати з Сеймуром Креєм. Тому нам потрібна була векторна архітектура. Добре, У Сеймура, напевно, було вісім векторних інструкцій. Ну, нам потрібно було мати 150 векторних інструкцій. І це мали бути довгі вектори, вони не були короткими векторами. Так це тривало і тривало, і тривало. І ви знаєте, тим часом у DEC West ми начебто готуємося – ви думаєте, що ми будемо триматися, але це не так, ми начебто готуємось до створення однієї з цих систем . У нас є пропозиції щодо побудови цих систем, і ми взяли MicroVAX-1 і фактично перетворили його на виконання коду Prism, щоб люди могли справді розробляти програмне забезпечення. І ми дійшли до моменту, коли компанія просто сказала: «Ми скасовуємо Prism». І я пройшов через кілька... ми пройшли через багато ітерацій. Я б пішов до Мейнарда, спробував досягти консенсусу щодо того, що ми маємо робити. Я б повернувся додому, і незмінно це завжди було щось більше, і ми додавали людей. Тож ми виросли з 20 до 180 осіб. Отже, у нас була організація зі 180 осіб, і ми створювали якийсь туманний продукт на основі цієї нової архітектури в той час, коли компанія намагалася створити три таких машини. Один був у Marlboro, один у Littleton і один у Сіетлі. Тому нашу машину скасували. І наша операційна система, яка називалася Mica, була скасована. І я начебто... я пройшов через етапи, намагаючись знайти певну основу, де ми всі могли б домовитися про те, що ми збираємося будувати, повернутися. Я б продав людям це, і тоді вони розчарувалися б. Тому я сказав: "Е, я "Е, ящо, ймовірно, було чимало грошей у сьогоднішніх доларах. І це було б у 1988 році. Тож десь у цей період чимало людей, коли Prism було скасовано, вирішили, що, можливо, вони звернуться до Microsoft на протилежному боці вулиці та підуть до Microsoft. І один із людей, які заходили туди, розмовляв з Біллом, Біллом Гейтсом, про групу в DEC West і про те, що у нас є хороша група операційних систем, і, можливо, це буде те, що може його зацікавити. було організовано співбесіду, і я підійшов і поговорив з Біллом про те, що їм цікаво робити, і що вони хочуть робити. І подивіться, чи мені було цікаво. І їхнє головне занепокоєння полягало в тому, що Intel недостатньо швидко просуває архітектуру X-86 і що процесори RISC збираються випередити їх, і якщо процесори RISC випередять їх, тоді все програмне забезпечення для ПК, яке вони розробили, більше не буде цінним. І що вони повинні щось робити в RISC. І якщо вони збиралися щось робити в RISC, тоді їм потрібна була нова операційна система, яка була б написана не на асемблері, а на портативній мові, щоб вони могли працювати на кількох різних архітектурах. І тому я начебто слухав усе це, і мені було дуже цікаво створити власну компанію. І тому я покинув інтерв’ю, думаючи: «Ну, я не думаю, що мене це справді цікавить». І якийсь, знаєте, час... або, знаєте, пару місяців, ми обмірковували це все вчотирьох. І нарешті ми зібрали всіх венчурних компаній і отримали від них зобов’язання щодо грошей.

А до того, як ми... ми взяли зобов'язання... хлопче, ти послухай, як вони говорять, ми були найкращими людьми у світі! Але як тільки ми взяли зобов’язання, наша цінність, здавалося, трохи зменшилася. І вони трохи більше висловлювалися щодо того, чи зможемо ми справді керувати компанією чи ні, і чи зможемо ми розробити продукт, навіть незважаючи на те, що ми мали хорошу історію розробки продукту. Тож це трохи влізло мені під шкіру. І приблизно в той самий час Стів Баллмер, який працював у Microsoft і був головою фінансового відділу Microsoft, подзвонив і сказав: «Знаєш, про що ти думаєш?» І я сказав: «Ну, я думаю, що ми дуже близькі до того, щоб створити цю компанію, і, ймовірно, ми відмовимося – або я, ймовірно, відхилю пропозицію Microsoft». І він сказав: «Боже, чому б вам не дати мені шанс переконати вас у зворотному?» І я сказав: "Ну, так, добре". І він сказав: «Ну, як щодо сніданку в Денні, знаєте, у суботу вранці о сьомій годині». Або я не знаю, можливо це був ранок неділі. Я маю на увазі, але це було рано. І я сказав: "Так, добре". Тож ми вчотирьох пішли до Денні й сіли. А Стів такий енергійний хлопець і позитивно мислить! І тому він починає роботу з продажу, і, я думаю, найкращий спосіб – те, що ви можете сказати, це він обдурив нас! <сміх> Тому що до того часу, як ми пішли, ми всі були готові зареєструватися. І ми зробили. Ми вирішили не створювати нашу компанію, яка, на мою думку, була чудовою – оглядаючись на це назад, можливо, ми були б просто ще однією серверною компанією, якби ми не змогли розробити якусь – насправді, ми засновували апаратну компанію. І якби ми не мали передбачливості швидко перетворити цю компанію на програмне забезпечення, у нас були б проблеми. Насправді, цікавою річчю, яку ви можете знайти тут, є те, що ми справді збиралися запустити UNIX на цій коробці через час, який знадобився, щоб фактично створити щось власне. І те, що це було б несумісно з усім. Отже, очевидно, ми не могли виробляти І те, що це було б несумісно з усім. Отже, очевидно, ми не могли виробляти І те, що це було б несумісно з усім. Отже, очевидно, ми не могли виробляти

те, що сумісно з VAX, тож наступним найкращим був UNIX. І ми вирішили, що Mach є найкращим прикладом системи UNIX. Тож ми фактично збиралися використовувати Mach на цьому сервері. Але в будь-якому випадку Баллмер обдурює нас, і ми всі вирішуємо зареєструватися та піти працювати на Microsoft. І тому, знаєте, я негайно звільнився. Вони все ще працюють на DEC. І як я пішов у п’ятницю та приєднався до Microsoft у понеділок, а наступного понеділка ці інші троє хлопців пішли за мною. І тоді ми... Я не хочу сказати, що ми вербували, тому що ми насправді не вербували людей, але люди запитували нас про можливості. І, звичайно, ми готові до можливостей, тож нам вдалося залучити чимало людей. Частково в тому, що вони звернулися до Microsoft, вони хотіли портативну операційну систему, але мені подобається її апаратна частина, теж, маючи це. Отже, ми переконали їх, або я переконав їх, що я повинен мати апаратну групу та програмну групу, і що ми виготовимо... апаратна група фактично виготовить перший ПК на базі RISC, який група програмного забезпечення вироблятиме операційну систему для. Тож ми змогли залучити... Вибачте, ми не змогли залучити, ми змогли задовольнити...

Сейверс: Думаю, термін давності давно минув.

Катлер: Термін позовної давності давно минув. Нам вдалося залучити цих людей з DEC, які були найкращими виконавцями в DEC West, і тому ми отримали найкращих хлопців із обладнання та програмного забезпечення. Було приблизно 10/10 або щось подібне. І ми найняли ще кількох людей. Ми найняли... ми мали, частково в групі було те, що ми... група обладнання, а не група програмного забезпечення... група програмного забезпечення, Microsoft хотіла переконатися, що у нас є люди з Microsoft у групі програмного забезпечення, інакше ми просто створить щось, що було б DEC, культурною річчю DEC, чи не так? Тож у нас був, насправді, я думаю, у нас був один, один хлопець із програмного забезпечення, і він був досить хорошим – або він був гучним хлопцем із Microsoft, і в нього було багато ідей. Що насправді дуже добре узгоджується з нашим про те, як створити операційну систему. На той час Microsoft вже кілька років працювала з IBM над OS/2. І ці стосунки складалися не дуже добре, і цей хлопець працював над цим, тому він був дуже радий приєднатися до нашої групи.

Сейверс: Отже, ви стрибаєте з парашутом у Microsoft і через короткий проміжок часу озирнулися навколо, що ви побачили? Як виглядала Microsoft у той час?

Катлер: Що ж, Microsoft не виглядала як DEC. Насправді я повинен сказати, що Microsoft була зовсім іншою компанією, ніж DEC. DEC було... те, що мені подобалося в DEC, і я думаю, що я можу чесно сказати, що я провів більшість своїх найкращих – найприємніших інженерних років у DEC між 1971 і 1980 роками, або, можливо, 1982 чи 1983-м - було DEC була переважно інжиніринговою компанією. Ним керували переважно інженери. Інженери запропонували продукти. Вони спілкувалися з клієнтами. Вони намагалися випускати дуже якісну продукцію. І випустити їх на ринок. І тоді маркетингова частина DEC не була... я б сказав, що в ті роки була справді сильною. Я думаю, що після цього воно стало сильнішим. Набагато сильніше, тому що фокус компанії став набагато більше маркетинговим, ніж інженерним. Але Microsoft була дуже маркетингово орієнтована. Microsoft була... поки вони продавали програмне забезпечення для ПК DOS IBM, тож вони були дуже маркетингово орієнтовані, що, знаєте, я вважав... мені це подобалося, тому що... мені це подобалося і мені це не подобалося. Мені це сподобалося, тому що це було... я збирався мати групу маркетологів, які справді збиралися випускати проекти чи продукти. З іншого боку, мені це не подобалося, тому що вони могли прикластися до того, що ми збираємося робити. І виявилося, що оригінальна версія NT була в значній мірі інженерною справою. За винятком кількох речей, і це було те, що на додаток до будучи портативною, Microsoft хотіла, щоб система була сумісна з кількома операційними середовищами. Таким чином, це привело нас до архітектури в NT, яка допускала б різні особистості підсистеми. І тому нам довелося задовольнити IBM і запустити OS/2. Звичайно, ми хочемо запустити DOS. І тоді інша річ, яка була великою, була дуже популярною. Великим, був популярним, був POSIX. Це стандартизовані інтерфейси UNIX. Отже, індивідуальність цієї речі мала бути цією багатогранною річчю. Отже, давайте подивимося, я намагаюся думати. Чому я пішов цією дорогою?

Катлер: О, гаразд, нас підсадили.

Катлер: Тож у будь-якому разі люди Microsoft або Microsoft начебто виділили цей рівень, але жодного з інших рівнів. Решта рівня була досить інженерною. І ми взялися за розробку Windows NT майже так само, як і за розробку VMS. За винятком того, що з точки зору Windows NT ми вирішили створити набагато більш детальну специфікацію системи. У VMS у нас була невелика група, і ми витрачали багато часу на розмови. І ми зробили деякі специфікації. Але це були досить рудиментарні характеристики. Для NT ми написали величезну специфікацію. І я б сказав, що це було більше шести місяців, про те, як буде працювати вся система, щоб люди могли підібрати специфікацію. Коли приходили нові люди, вони могли підібрати специфікацію та зрозуміти її, прочитати код і фактично зрозуміти, що відбуватиметься. Наша перша прогнозована дата поставки ОС була приблизно два роки. На створення першої ОС нам знадобилося п’ять років. Я міг би ніколи... якби ви запитали мене навіть сьогодні, чи тоді це зайняло б п'ять років, я б сказав: "Ні", я б сказав: "Ми могли б зробити це за два роки". Але було ще багато чого зробити. VMS не мала графічного інтерфейсу користувача. Ми повинні були це зробити. У нас не було проблеми з підсистемою у VMS. У нас було кілька особистостей. Нам довелося запустити двійкові файли PDP-11. І ми розробили те, що називається AME, яке було виконавчим органом міграції додатків. І ми запустили все—насправді, саме так ми розробили програмне забезпечення VMS, запустивши програмне забезпечення 11 на VAX. Я міг би ніколи... якби ви запитали мене навіть сьогодні, чи тоді це зайняло б п'ять років, я б сказав: "Ні", я б сказав: "Ми могли б зробити це за два роки". Але було ще багато чого зробити. VMS не мала графічного інтерфейсу користувача. Ми повинні були це зробити. У нас не було проблеми з підсистемою у VMS. У нас було кілька особистостей. Нам довелося запустити двійкові файли PDP-11. І ми розробили те, що називається AME, яке було виконавчим органом міграції додатків. І ми запустили все—насправді, саме так ми розробили програмне забезпечення VMS, запустивши програмне забезпечення 11 на VAX. Я міг би ніколи... якби ви запитали мене навіть сьогодні, чи тоді це зайняло б п'ять років, я б сказав: "Ні", я б сказав: "Ми могли б зробити це за два роки". Але було ще багато чого зробити. VMS не мала графічного інтерфейсу користувача. Ми повинні були це зробити. У нас не було проблеми з підсистемою у VMS. У нас було кілька особистостей. Нам довелося запустити двійкові файли PDP-11. І ми розробили те, що називається AME, яке було виконавчим органом міграції додатків. І ми запустили все—насправді, саме так ми розробили програмне забезпечення VMS, запустивши програмне забезпечення 11 на VAX. Ми повинні були це зробити. У нас не було проблеми з підсистемою у VMS. У нас було кілька особистостей. Нам довелося запустити двійкові файли PDP-11. І ми розробили те, що називається AME, яке було виконавчим органом міграції додатків. І ми запустили все—насправді, саме так ми розробили програмне забезпечення VMS, запустивши програмне забезпечення 11 на VAX. Ми повинні були це зробити. У нас не було проблеми з підсистемою у VMS. У нас було кілька особистостей. Нам довелося запустити двійкові файли PDP-11. І ми розробили те, що називається AME, яке було виконавчим органом міграції додатків. І ми запустили все—насправді, саме так ми розробили програмне забезпечення VMS, запустивши програмне забезпечення 11 на VAX.

Сейверс: повністю необмежена архітектура вводу-виводу тощо на ПК.

Катлер: Правильно. Тому нам потрібно було ще багато чого зробити. І ми почали з такої ідеї, що ми збираємося виготовити перший ПК RISC і ми збираємося виготовити програмне забезпечення для нього, і ми робимо це – добре, я не можу сказати, що ми припустилися цієї помилки. Ця помилка вже була зроблена для нас, коли ми прийшли туди, коли Intel у той час виробляє i860. І це одна з найшвидших машин RISC у певних програмах. І ці додатки в основному графічні. Тому Microsoft хотіла використати це як мікропроцесор для нашої першої еталонної реалізації. Ми збиралися створити еталонну реалізацію 860, і ми запросили одного з OEM-виробників, а саме Olivetti, який підписався на створення цього. Отже, ми збиралися побудувати еталонну систему, а вони мали взяти проект, зробити його придатним для виготовлення та виготовити. Ми збиралися створити програмне забезпечення. Але пізніше ми з’ясували, що i860 дуже хворий. У ньому було багато помилок, які зробили його непридатним для використання як систему на основі ОС. У нього були деякі особливості, які зробили його дуже приємним для світу графіки, але не дуже добре для світу операційних систем. Мав віртуально тегований кеш. Тож щоразу, коли ви перемикаєте контекст, ви очищаєте кеш, оскільки він містить усі віртуальні теги з останнього адресного простору, у якому ви запускали. Так чи інакше, першу версію зайняло п’ять років. Тож я вважаю, що початкове запитання було: "Наскільки іншим було середовище?" Що ж, середовище було значно іншим, тому що DEC була інженерною компанією, яка завжди базувалася на інженерній досконалості. Майкрософт, на мою думку, цілком справедливо, я б сказав, що це компанія, що базується на маркетингу. І вони не базувалися на інженерній досконалості. Отже, між нашою культурою та

культура Microsoft. Але я думаю, що ми прищепили багато цього в культуру Microsoft, але у нас все одно відбувалося багато речей, які були поза нашим контролем і були в культурі Microsoft. Тож це значно подовжило проект, а середовище... воно було зовсім іншим.

Сейверс: Десь у дорозі ви сказали мені: «У Microsoft було багато програмістів, але не було розробників програмного забезпечення». І ви повинні були принести дисципліну програмної інженерії в Microsoft.

Катлер: Так, я думаю, що однією з речей, які ми привнесли, була інженерна дисципліна створення програмного забезпечення, і я не думаю, що Microsoft мала інженерну дисципліну, яку ми мали на той час. Звичайно, ви знаєте, це було 28 років тому. Це довгий час, і дисципліна в Microsoft зараз, я б сказав, чудова. Там багато речей на місці. Це інша атмосфера, яку ми мали з оригінальною командою NT, тому що наша команда була маленькою. Знаєте, ми починали з 25 хлопців. Наприкінці версії 1 були

150. Наприкінці версії 4 було 400, що є великим – сьогодні це 4000.

Сейверс: Тепер на цьому шляху багато чого додається до того, що таке NT. Гадаю, у вас були менеджери програм, я думаю, це була назва.

Катлер: Що стосується культури та середовища, то в DEC у нас були менеджери програм, але менеджери програм були на кшталт... вони були в якомусь сенсі квазімаркетинговими людьми. Вони не намагалися керувати інженерними зусиллями. Інженерними роботами керували інженери. Отже, на початку між мною та програмними менеджерами Microsoft виникла велика суперечка щодо того, хто що робив. І я написав... хотів би я знайти цей лист, який написав. Але я написав цю велику річ, великий лист нашому менеджеру програми про його та мою роботу, у якому виклав, якою, на мою думку, є його робота, а що — моя робота. І це в основному вийшло, тому що ми майже працювали так, як у DEC. Але з часом менеджери програм Microsoft взяли більш безпосередню участь і контролювали те, що відбувається.

Сейверс: Отже, у вас є ця надзвичайно складна річ. Кілька платформ, на яких ви збираєтеся працювати, портативність. Зберігати контроль над цим і тримати всіх у русі протягом п’яти років стає досить складним завданням.

Катлер: Отже, трохи про складність того, що ми будуємо. Ми говорили про 860 і проблеми з 860, ну, на півдорозі, ми працювали лише близько року, і ми вирішили, що ми не можемо піти з 860. І тому ми сказали: " Що нам робити?" Тож ми сказали: «Ну, як щодо MIPS? MIPS розробляє R4000. Це платформа, яку ми повинні зробити першою». Тож наші апаратні групи перейшли на R4000, і ми почали рухатися в цьому напрямку. Тепер просто для того, щоб зробити велику різницю з операційною системою, тому що те, як операційна система структурована або була структурована, полягає в тому, що ми беремо речі, які були абсолютно портативними, і вони все ще були портативними, а потім речі який був специфічний для апаратної архітектури, було розділено так, що вам просто потрібно було його замінити. Отже, перше, що сталося, DEC дізнався про те, що ми робимо, і сказав: «Ну, Боже, ми створюємо робочу станцію R3000. Чому б вам також не підтримати R3000?» Тож, мабуть, по-дурному ми сказали: «Добре, ми також підтримаємо 3000». Що ж, це поставило нас у певні труднощі, тому що 3000 не зовсім сумісна з 4000, тому зараз ми створюємо для двох платформ. Тож у нас були R3000 і R4000. І незабаром після цього сказав: «Ну, схоже, це триватиме трохи довше, ніж ми думали. Можливо, ми це зараз створює для нас певні труднощі, тому що 3000 не зовсім сумісна з 4000, тому зараз ми створюємо для двох платформ. Тож у нас були R3000 і R4000. І незабаром після цього сказав: «Ну, схоже, це триватиме трохи довше, ніж ми думали. Можливо, ми це зараз створює для нас певні труднощі, тому що 3000 не зовсім сумісна з 4000, тому зараз ми створюємо для двох платформ. Тож у нас були R3000 і R4000. І незабаром після цього сказав: «Ну, схоже, це триватиме трохи довше, ніж ми думали. Можливо, ми

слід додати 386 назад у суміш. Ви знаєте, Intel випускає, я думаю, що це 386-25, 25 мегагерц." <сміх> Давайте додамо це, тож тепер ми починаємо – ми не будуємо апаратне забезпечення, тому що є галузева інфраструктура для створення Базова система x86. Тож ми нічого там не робимо. І тому зараз ми створюємо в основному три цілі та три робочі середовища. І графічний інтерфейс. І тепер DEC повертається з альфа-версією та каже: «Боже, ми хочемо щоб також запускати Windows на альфа-версії". І ми сказали: "Добре, ми почали робити альфа-версію". І тоді IBM каже: "Ну, боже, поки ви все це робите, давайте зробимо Power PC. «Тож ми фактично створюємо чотири платформи. Ми створюємо чотири платформи, якщо вважати MIPS лише 1, якщо вважати 2, тоді ми робимо п'ять. Крім того, те, що сталося десь на початку 90-х, у нас була ця штука на 16 бітах, яка працювала в DOS і була шаром. Це була програма, яка працювала поверх DOS, вона називалася Windows. І ми створили Windows 1.0, галузь сказала: «Ха-га». Ми зробили Windows 2.0, галузь сказала: "Ха-га". Ми розробили Windows 3.0, галузь сказала: «Ха-га». Ми зробили Windows 3.1, ми продали 16 мільйонів копій за півроку! Це було як неймовірно! Тож Білл каже: «Гм, мабуть, нашим основним операційним середовищем більше не буде OS/2, а Windows». Тож ми перейшли з основного операційного середовища OS/2 із диспетчером програм, який був їхнім графічним інтерфейсом, на Windows. І коли ми запровадили Windows, ми також запровадили всі вимоги щодо сумісності з Windows 16. Отже, ми працюємо на всіх цих платформах. Ми використовуємо ці різні середовища, ми використовуємо 16-розрядний емулятор DOS. Ми використовуємо 16-розрядний емулятор Windows на Windows. Ми використовуємо 32-розрядні емулятори Windows на Alpha, Power PC і MIPS. Усі ці речі, щоб дістатися до першого випуску. Тепер перший випуск фактично підтримував лише MIPS і x86. І я думаю, приблизно через півроку ми зробили ще один проект під назвою Daytona, який був іншим релізом. І це включало Alpha, яка була 3,5, а потім приблизно через шість місяців ми зробили Power PC. Ось чому це зайняло п’ять років. Power PC і MIPS. Усі ці речі, щоб дістатися до першого випуску. Тепер перший випуск фактично підтримував лише MIPS і x86. І я думаю, приблизно через півроку ми зробили ще один проект під назвою Daytona, який був іншим релізом. І це включало Alpha, яка була 3,5, а потім приблизно через шість місяців ми зробили Power PC. Ось чому це зайняло п’ять років. Power PC і MIPS. Усі ці речі, щоб дістатися до першого випуску. Тепер перший випуск фактично підтримував лише MIPS і x86. І я думаю, приблизно через півроку ми зробили ще один проект під назвою Daytona, який був іншим релізом. І це включало Alpha, яка була 3,5, а потім приблизно через шість місяців ми зробили Power PC. Ось чому це зайняло п’ять років.

Сейверс: Легко зрозуміти заднім числом. Багато чого змінилося.

Катлер: Багато речей змінилося.

Сейверс: Отже, для того, щоб зберегти команду, використовується сумнозвісний стиль управління Дейва Катлера. Поговорім про збереження команди.

Катлер: Раніше я сказав, що завжди вважав себе лідером, а не менеджером. Тому я завжди намагався бути лідером, який є частиною команди, а не тим, хто відокремлений від команди. Тому я завжди частина команди. Якщо команда напружена і притиснута до стінки, то я в стресі і притиснутий до стінки. Тому, я думаю, у нас не було проблем із згорілими людьми. Знаєте, наші люди цілих п'ять років майже простояли. Хоча певні наслідки були. Я маю на увазі, що люди розлучаються, знаєте, траплялися й інші речі. І ми мали дуже значне виснаження. Я маю на увазі, просто дуже невелике виснаження. Всі повірили в продукт. І інше, що ми робили, — щоп’ятниці ввечері ми влаштовували вечірку. Ми назвали це WIM. І WIM була щотижневою інтеграційною зустріччю.

Тому що зрештою ми залучили мережеву групу. Спочатку у світі ПК мережева група була окремою від групи операційних систем і була лише додатком. Знаєте, це просто... це якась інша програма. Якщо ви хочете виконувати мережеві операції, ви запустили програму для цього. Це не було створення операційної системи. І ми могли б весь час планувати вбудувати його в операційну систему з моделлю VMS. Тож ми досить швидко зростаємо, коли ми залучаємо деякі з цих груп, і ми переходимо з 20 людей до 150 чи будь-якої іншої. І тому він сказав: «Ну, чому б нам не провести це... у нас будуть зустрічі щоп’ятниці вдень, і ми підемо за пивом, піцою та чіпсами, і ми зустрінемося, і просто всі познайомляться один з одним". Тож це переросло у величезну річ! Я маю на увазі, я можу уявити, що п’ять років і щоп’ятниці ввечері що ви це робите. Ми починаємо, ми в кімнаті приблизно такого розміру, а закінчуємо у величезній кімнаті! І ми починаємо з того, що я посилаю менеджерів з розробки, піді мною було чотири менеджери з розробки, Я відправляю їх у Safeway, щоб вони купили кілька сортів пива, взяли піцу та привезли їх назад, аж до кінця, коли у нас буде повне обслуговування від Marriott. Marriott привозить усе, і ми переходимо від чіпсів, сальси, пива чи піци до креветки та всілякі речі, які обслуговують. Бочки з пивом. Я маю на увазі, це було цікаво. А ще були деякі речі, які були, у нас завжди щось відбувалося, і ми намагалися змусити людей почуватися краще про те, що відбувається, і про те, у якому стресі вони перебувають. Я знаю, що деякі люди відчували, що перебувають у стані сильного стресу, і іноді вони б зламалися, але я думаю, що загалом ми тримали все разом досить добре.

Сейверс: Випускаємо пару з командою. Катання на лижах, гонки.

Катлер: Ну, один із способів, як ми трохи випустили пар, був насправді хлопець, який був хлопцем з Microsoft, який приєднався до нас на початку, вирішив, що було б чудовою ідеєю поїхати в Лагуна Сека і піти в Russell Racing. Школа. Тож я думаю, що вісім із нас пішли до школи, і ми пішли до школи для початківців, яка, я думаю, тривала чотири дні. А ми їхали в вільній машині Mazda. І знаєте, було добре трохи випустити пар. І для мене це дійсно відкрило очі про водіння гоночного автомобіля. Я справді не дуже добре це вмів. Або не був таким хорошим, як я думав, що мав би бути в цьому. І школа для початківців, вони просто навчать вас, як керувати автомобілем, про динаміку автомобіля, перевантаження, проходження поворотів і таке інше. Але тоді у них є просунутий курс, де ви фактично в кінці курсу ви можете взяти участь у перегонах. Тож деякі з нас вирішили: «Ну, ми теж хотіли б піти на це». Тому, я не знаю, закінчується пара/три місяці, і ми йдемо вниз і робимо це. І тому ми проводимо гонку. Ми проходимо передову школу, а вони ще щось роблять. І мені це стає трохи цікавіше. І ми завершуємо це, ми беремо участь у нашій гонці, і це було весело, тож я подумав: «Ну, можливо, знаєте, у них є School Series, те, що вони називають School Series». І ви в основному їдете раз на місяць, і ви берете участь у перегонах у суботу, потім у неділю, а потім повертаєтеся додому. Деббі спустилася і виконала один для початківців, і вона виконала один для просунутих. І ми з нею ходили туди щомісяця, я думаю, що ми спускалися з, о, десь у березні до вересня, щось на зразок цього. Кожен місяць, тож це було десять гонок чи щось подібне. Тож я це зробив. І це було весело. І тоді у них був... щороку вони проводили те, що вони називали Pro Race. І професійна раса, яку вони б... у них не було регуляторів у системах, але вони начебто налаштовували б... вони б трохи їх відкрили. Вони б перепрограмували ECU, блок керування двигуном, і дали їм трохи більше кінських сил.

І вони казали: «Зараз ми йдемо на Pro Race», а Pro Race означало, що є призовий пакет, і ви можете виграти трохи грошей. Я думаю, що, мабуть, вершина була 10 тис. або щось подібне. Але це залучило б багато водіїв, які були досить хорошими. Тож я зробив один із них. Я думаю, що я закінчив передостаннім, тільки тому, що один хлопець, мій перший, тільки тому, що інший хлопець був гіршим за мене. Потім я зв’язався з хлопцем, який був там одним із інструкторів, і іншим хлопцем, який володів гоночною командою, яка імпортувала автомобіль Atlantic із Нової Зеландії. І тоді я почав серйозно займатися гонками. І тому я володів цією машиною, і він брав участь у перегонах на цій машині одного року, а це був 1995 рік, а наступного року я вирішив, що, ну, ми дійсно повинні мати новий автомобіль для перегонів. Тож я купив нову машину, і постало питання, що робити зі старою машиною. Тож я заліз у стару машину, і мені було дуже добре. Тож я вирішив: «Що ж, я буду брати участь у цій серії». Тож я почав брати участь у Атлантичній серії, і я провів 56 гонок у цій серії. І потрапив у кілька досить жахливих аварій. Нічого, що я дійсно сильно постраждав. Але один у Лагуна Сека є наче сумно відомий, тому що ESPN показував це знову і знову і знову, я не знаю, п’ять хвилин трансляції чи щось таке. І один із поворотів я зробив поздовжнє сальто. Тож ви думаєте про фліп як про те, що йде в кінці. Це був перекид бочки. Я зробив таке сальто і приземлився на вершину. І це було в кутку, де було дуже пильно, і пил літав, і були великі хмари пилу.

Сейверс: Який це був поворот?

Катлер: Це був 10-й поворот у Лагуна Сека.

Сейверс: Отже, швидка машина

Катлер: Праворуч.

Сейверс: Праворуч, так.

Катлер: І ESPN підхопив це, і вони просто відтворили це... вони відтворили це знову і знову, тому що у них є певний проміжок часу, щоб... жовтий згас, вони повинні очистити трасу, а потім вони повинні вивести шкідників і поставити машину вертикально. Отже, гонка,

Сейверс: Зупинилися.

Катлер: Зупинився. Але вони просто продовжують грати в це знову і знову і знову. <Сміх> Тож це був мій велика крах. Мій найкращий результат, одного разу я фінішував восьмим на Milwaukee Mile. У цій конкретній серії ми брали участь у гонках у Монтереї, Мексика, що було справжнім... це справді відкрило очі. Гоночні траси тут досить безпечні. Там іподром не був справді безпечним. Я брав участь у перегонах у Хоумстеді. Я брав участь у перегонах у Клівленді в аеропорту; Мід-Огайо, що знаходиться за межами Колумбуса; Монреаль; Труа Рів'єра, яка знаходиться вгорі біля міста Квебек; Ванкувер, Британська Колумбія, Портленд, Лонг-Біч.

Сейверс: Дорога Америка?

Катлер: О, так, Road America. Насправді Road America. Це в Елкхарті, штат Вісконсін. Так, у мене була велика аварія на... моя друга за величиною аварія, або, можливо, моя перша найбільша аварія була на Road America. Там є поворот, який вони називають The Kink, а це приблизно 140-150 миль на годину. А я не впорався з керуванням і врізався там у кам’яну стіну. І –

Сейверс: Ой.

Катлер: Я вийшов з машини, і машина так хиталася, і я не міг зрозуміти, чому це так, і я подивився вниз, і всі чотири колеса зникли. <сміх> Я просто сиджу в машині, знаєте, машина побудована з так званої монококової ванни, і я в ванні, а двигун все ще позаду, але немає жодного колеса, вони всі пішли. Тож я брав участь у гонках на Road America.

Сейверс: Ваш улюблений?

Катлер: Миля Мілуокі, далеко. Назарет, штат Пенсільванія. Я теж там бігав.

Сейверс: Чи є аналогії від перегонів до розробки програмного забезпечення?

Катлер: Так, насправді, я думаю, що є. Це фокус. Я завжди був людиною, яка дійсно могла зосередитися на своїй роботі. А перегони - це... водіння гоночного автомобіля - це зосередженість. Я маю на увазі, що те, що сталося десять мілісекунд тому, зникло. Ви збираєтеся зосередитися на тому, що буде і що станеться. Тож я думаю, що є певна аналогія щодо справжнього успіху, я маю на увазі, що в будь-якій справі потрібно зосередитися на тому, що є важливим, і на тому, чого ви повинні досягти, щоб досягти успіху. Тож у гоночному автомобілі це був лише ще один приклад цього.

Сейверс: Отже, надінтенсивність концентрації. Коли ви пишете код, як ви цього досягаєте? Ви можете витримати музику або хочете бути в тихому офісі?

Катлер: Загалом, шум мене не сильно турбує. Я б волів, щоб хтось не був... зараз на роботі є один хлопець, який свистить. І це не проблема, але він свистить у коридорі, а я кажу: «Мені це справді не подобається». Але загалом шум мене не сильно турбує. Але я зосереджуюсь на тому, що відбувається, особливо якщо я пишу новий фрагмент коду, ви знаєте, я напишу код і проведу, можливо, три чи чотири ітерації, щоб виконати код у своєму розумі. Усі шляхи помилок, усі шляхи, якими він може пройти, щоб перевірити, чи зможу я довести, що він правильний, перш ніж я навіть запущу код. І більшість часу, коли я запускаю код, він майже запускається з першого разу. Можливо, це не зовсім правильно, але запуститься. Він не вийде з ладу. Отже, це можливість зосередитися на тому, що відбувається,

Сейверс: У програмі NT це було знесення багів. Як би ви змінили процес, щоб створювати менше помилок і полегшити їх виправлення?

Катлер: Найпростіший – мабуть, найлегші помилки для виправлення. Ну, питання полягає в тому, як полегшити виправлення помилок і...

Сейверс: І менше їх.

Катлер: Я думаю, що їх менше – це, ймовірно, легше з двох, тому що чим менше помилок, тим важче буде вирішити ті, що залишилися. І найважче вирішити проблеми, пов’язані з синхронізацією. Вони не стосуються правильності потоку коду. Вони пов’язані з правильністю синхронізації, де немає правильних бар’єрів, немає правильних блокувань, або є умови змагання між шляхами коду, або щось таке. Однією з речей, яка також погіршила ці п'ять років, була багатопроцесорна обробка. Коли я пішов у Microsoft, у мене була бджола в капоті, що ми збираємося виробляти MP-системи. І більше ніхто не виробляв МП системи. DEC мав, у той час у них був VAX 782, який був кумедною асиметричною штукою. І у нас був 11/70, який насправді був SMP, але була якась проблема з Unibus, тому ми вирішили не виробляти його. Отже, проблеми SMP, синхронізація є великою проблемою. Проблема з меншою кількістю помилок, я вважаю, полягає в самому інженерному процесі, і в людях, яких потрібно мати, якість має починатися знизу вгору. Він не може початися зверху вниз. Ви не можете законодавчо закріпити якість, якість має бути чимось вродженим у всіх на найнижчому рівні. І будь-яка ланка на найнижчому рівні, яка не виробляє якісну частину, створює помилки в лінії, тому що вони взаємодіють з іншими частинами системи. Якщо ви створюєте нижчі рівні системи, то ваш важіль, що стосується створення проблем на верхніх рівнях, дуже високий. Тож я вважаю, що зменшення кількості помилок означає більше думати про якість і приділяти їй більше уваги. Я не думаю, що у вас обов’язково є така річ, де: «Ну, потім ми зробимо 100-відсотковий тест. Знаєте, ми зробимо все, а потім перевіримо, наскільки це добре». Його потрібно вбудувати для початку. Тож я думаю, що створення систем із меншою кількістю помилок означає приділяти цьому увагу весь час. І ні... для мене я ненавиджу, коли на мене створюють помилки. Мені це зовсім не подобається. І я не хочу, щоб ця помилка існувала на мені довше, ніж мені потрібно. Я кину все, щоб виправити цю помилку, тому що я знаю, що можу це виправити. Тому має бути такий менталітет. Я маю на увазі, що багато людей кажуть: «О, так, у мене 50 помилок. О, знаєте, я їх виправлю». Ну, це як кинути палити. Ви знаєте, коли найкраще кинути палити? Зараз! Не минуло й години. Або через день, або через тиждень. Це прямо зараз! Тож найкращий час виправити помилку – це зараз. Так було б менше багів. Щоб їх було легше виправити, я не знаю, як би ми могли їх легше виправити, крім створення кращих інструментів для аналізу того, що відбувається, я думаю, це насамперед спосіб полегшити їх виправлення. І зараз у нас є багато інструментів. У нас є багато інструментів, які роблять те саме. Ви знаєте, хтось сказав: «Ну, це хороший інструмент, але я хотів би, щоб інструмент зробив це. У мене немає інструменту, але я думаю, що я міг би створити інструмент, який був би трохи кращим, зробіть це, і, можливо, ми зможемо знайти щось трохи краще". І тому ми маємо багато інструментів. У нас є багато інструментів для аналізів коду. Одна з великих проблем, з якою ми зіткнулися на етапі еволюції NT, полягала в тому, що ми зазнали великої атаки на безпеку, стіни або чогось іншого. Десь після 2001 року, десь там. Інтернет, ми справді почали використовувати Інтернет десь наприкінці 90-х. І в Інтернеті раптом виникли проблеми з людьми з вірусами, які намагалися атакувати вашу систему. Тож ми розробили кілька інструментів, які аналізували джерело та намагалися знайти місця, де у вас є переповнення буфера – це найбільше. І кількість переповнень буфера, яка у нас була, була просто вражаючою. І це було так, ніби у нас є цей інструмент, і інструмент каже: «Подивіться, прямо тут, це може переповнитися». І це було чудово, я маю на увазі, що вдалося зменшити помилки. Навіть такі речі, як, я маю на увазі, арифметичне переповнення, можуть спричинити помилку, тому що, можливо, ви обчислюєте розмір буфера, який хочете виділити, оскільки у вас є кількість байтів, і ви виконуєте це обчислення, і, боже, це переповнення. А тепер, схоже, вам потрібен маленький розмір. Тож ви виділяєте цей розмір, а потім використовуєте цей інший розмір для передачі даних у нього, і раптом у вас виникає проблема, тож у вас є інструменти, які аналізують код, і насправді вказувати місця, де є помилки. І ми справді виправляємо їх, ніби це помилки. Проблема з цими інструментами полягає в тому, що вони є статичним аналізом і мають багато помилкових спрацьовувань. Тож ви бачите багато речей, які насправді не є проблемами. І вони не бачать деяких речей. Можливо, у вашому коді була логіка, яка унеможливлювала те, про що він скаржиться. І він скаже: «Гей, це погано». Тому їх потрібно відфільтрувати. І тому ми також маємо способи відфільтрувати це. Можливо, у вашому коді була логіка, яка унеможливлювала те, про що він скаржиться. І він скаже: «Гей, це погано». Тому їх потрібно відфільтрувати. І тому ми також маємо способи відфільтрувати це. Можливо, у вашому коді була логіка, яка унеможливлювала те, про що він скаржиться. І він скаже: «Гей, це погано». Тому їх потрібно відфільтрувати. І тому ми також маємо способи відфільтрувати це.

Сейверс: Якщо ви повернетеся трохи назад до того, щоб змусити програмістів справді створювати хороший код, чи існує школа Дейва Катлер:а, як змусити програміста рухатися в цьому напрямку?

Катлер: Чи є у мене спосіб спонукати людей створювати хороший код? Я вважаю, що єдиний спосіб, яким я можу сказати, що я маю – допомагати людям створювати хороший код – це власним прикладом. Все, що я роблю, я намагаюся робити якнайкраще. І всі бачать джерело. І, очевидно, вони бачать, що у мене не дуже велика чи нульова кількість помилок. Вони дивляться на мій код, і я сподіваюся, що це дійсно допоможе їм стати кращими програмістами. Але інший аспект цього полягає в тому, що молоді люди починають по-справжньому закріплювати в собі важливість якості. Я маю на увазі, що для мене немає нічого гіршого за програмне забезпечення, яке не працює. Я маю на увазі, що я можу дуже засмутитися через програмне забезпечення, яке не працює. Там, де очевидно, що щось просто... я маю на увазі, це щось просте. Я маю на увазі, якщо щось не працює на вашому телефоні, або не працює на вашому планшеті, або це не працює на вашому ПК, який повинен працювати, це має вас обурювати, тому що це просто не повинно бути так, правильно? Це повинно бути... все, що не працює, має бути дрібницею. Можливо, тут є кілька помилкових пікселів. Або щось незначне. Насправді, багато помилок, які... які були та продовжують надсилатися проти NT, є такими речами. Це косметичні речі. І вони, як правило, мають низький пріоритет. Тож ці речі не засмучують, але це засмучує, коли у вас є щось, куди ви відправляєте продукт, і він стоїть у полі протягом чотирьох місяців, і раптом відбувається ця катастрофа, коли ви знищуєте чиїсь дані, а потім усе раптом це схоже на: «Ого, це справді проблема». Тож я думаю, що якість — це те, що починається з молодих людей і каже: «Гей, знаєте, ми справді повинні мати якість».

Сейверс: Отже, ми підійшли до 1993 року, я думаю, остаточна дата випуску NT? Або офіційний випуск. Відправлено мільйони копій.

Катлер: Початкова версія NT була випущена в 1993 році. Потім ми випустили NT 3.5, який отримав підтримку Alpha приблизно через шість місяців. І частина цього також була своєрідним очищенням, давайте покращимо продуктивність випуску системи. Ми не мали того рівня продуктивності системи в першому випуску, якого б хотіли мати. Це було трохи роздутим. Тепер роздутий у ті часи був таким, що, можливо, потрібно було 24 мегабайти. <сміх> На відміну від двох або чотирьох гігабайтів. Таким чином, Daytona була подвійною річчю, де це було... це було названо Daytona. Насправді це був випуск Daytona, і нашою великою справою там був іподром і все таке. І я думаю, що у нас насправді може бути... ну, у нас були деякі речі на іподромі, тому що ми всі ходили до школи перегонів. І ми включили підтримку Alpha. А трохи пізніше ми створили Power PC. Таким чином ми підійшли до кінця першого випуску, а потім наступним випуском була NT 4.0. І NT 4.0 був цікавим випуском, тому що наприкінці випуску 1, або ми насправді називали його 3.1, тому що Windows була 3.1. 16-бітна Windows була 3.1. І було відчуття, що ніхто не купить операційну систему 1.0. ніхто Отже, давайте почнемо з числа, яке не було 1.0, і, добре, ми б вибрали те саме число, що й 16-бітна річ. Тоді ми мали 3,5 і 3,5,1. І що ж, наступний мав бути 4.0. А тим часом з Баняна найняли ще одного хлопця. Його звали Джим Алчін, і він фактично... починав інший проект під назвою Cairo. І передбачалося, що Cairo буде системою, яка об’єднає деякі речі, які ви зараз бачите під час пошуку в Інтернеті. Тільки б локально. Нова файлова система з індексацією. Індексація всієї вашої пошти та всього іншого. І це було внутрішньо в Microsoft, воно називалося «Інформація у вас під рукою». І він розпочав цей проект, і він працював начебто паралельно з останнім випуском 1. Отже, коли ми почали випуск 2, ну, насправді це був NT 4.0, проект Cairo. Алчин фактично став моїм босом. І проект Cairo став частиною розробки NT. І нібито туди ми збиралися йти. І я дуже хвилювався з цього приводу, тому я запропонував інший проект під назвою... і ми назвали його Tukwila. І причина, чому ми вибрали Tukwila, полягає в тому, що ми знаємо, де Tukwila, і ми знаємо, як туди потрапити. Тільки б локально.

<сміх> Це просто вниз по вулиці. Тож я переконав Джима, що ми повинні... у нас є можливість зробити обидва одразу, а один викинути. І виявилося, що той, який ми викинули, був Каїром. І NT 4.0 була, мабуть, однією з найкращих систем, які ми створили. Звісно, ​​не функціонально. Але що стосується його прийняття, якості та продуктивності. Він містив... це було в 1996 році, тож це було одразу після Windows 95. Ми поговоримо трохи про цей родовід системи. Таким чином, він містив новий графічний інтерфейс користувача, який кардинально відрізнявся від 3.1. 3.1 був начебто, він був графічним, але ви начебто збирали речі разом. Ви створили своє меню, і вам довелося зробити цілу купу речей. І тоді інтерфейс користувача насправді мав усе це. Ви знаєте, все, коли ви отримали, система вже була встановлена ​​з меню «Пуск» і всім іншим. Отже, NT 4.0 мав новий інтерфейс користувача, і це була еволюція NT. Cairo також був би еволюцією NT, але він мав би нову файлову систему, нову оболонку, просто купу нових речей - нову поштову систему, усе. Тож я почав відволікатися від нашого... я заглибився в Windows 95 і чому виникла Windows 95. Windows 95 фактично побудована на кодовій базі DOS. Тож насправді це була 16-розрядна система з можливістю запуску 32-розрядних програм, і вона включала цей новий інтерфейс користувача. І насправді він був дуже популярним і продав багато систем, тож за цей період часу він продав набагато більше систем, ніж продала NT. Але NT продавався в місцях, де ви займалися бізнесом. Вам потрібен був певний захист, вам потрібно було запустити сервер – ви хотіли запустити файлові сервери чи сервери друку. Тоді це були єдині сервери. Тож NT був живий-здоровий і дуже здоровий. Але в той же час Windows 95 принесла компанії великі гроші. А потім вони продовжили роботу з тією самою кодовою базою для Windows 98, а потім з Millennium, який, я вважаю, був у 2000 році. Тож потім він загинув. Воно повністю померло. Це був нерозширюваний – він мав помилки. Це було сумно відомо тим, що просто повішали. Просто замерзло б. І це не було неочікувано,

Сейверс: І жахливий захист.

Катлер: Не було ніякого захисту.

Катлер: Жодного. Жодного. Одна з речей – ви не запитували мене про це, але я хочу сказати дещо про безпеку. Ви знаєте, ми спочатку почали мати справді надійну безпеку. І ми розробили оригінальну модель безпеки, яка була досить надійною. Але за нинішніми мірками зовсім інше. Тому що в ті часи ви захищали людей від доступу до файлів і системних ресурсів. Але це було не так, як у сьогоднішній системі безпеки, де хтось запрошує взлом прямо в систему. Вони у веб-переглядачі, натискають на щось, і тут з’являється програма, про яку вони навіть не знали. І раптом він використовує переповнення буфера, і бах! Це вносить щось в операційну систему, і тепер ви під контролем вірусу, чи не так? Так чи інакше, було багато суперечок про те, чи потрібно змушувати людей входити в систему чи ні. Тому що оригінальний ПК, ви знаєте, ви вмикаєте його, ось він! Ну, Білл не хотів входу. Ми говоримо про безпеку та той факт, що ми, можливо, на початку трохи скоротили систему за допомогою безпеки, тому що менталітет ПК був таким, що ви просто вмикаєте систему та використовуєте її. І ми дійсно мали... - ми вийшли з систем розподілу часу, де всі входили в систему, і все було спільно. І ви хвилювалися, що люди отримають доступ до ваших файлів. І боже, якщо це ПК, він у вас є, ви можете отримати доступ до своїх файлів. Таким чином, ми фактично розробили систему безпеки та побудували систему безпеки, і ми мали вхід, але були деякі аспекти системи, які ми робили не так добре, як могли. Один із них: коли ви встановлюєте програму, ви дійсно повинні встановити програму для користувача, який її встановив. Не для системи. Але оскільки це ПК, ви встановлюєте його для системи. Тож це була одна проблема, тому що тепер ви припускаєте, що всі збираються використовувати цю річ, і що якщо двоє людей мають дві різні версії, ну, ви не можете мати цього. Ви можете мати лише одну версію. А потім інше, що сталося з тим, що всі ці люди пересилали бінарні файли. І тому хтось мав би програму на кшталт Office, і вони перенаправили бінарний файл, а хтось мав би, можливо, програму бази даних, яка надсилала б бінарні файл. Той самий бінарний файл. Ніколи не перевіряли продукт інших хлопців, чи не так? Тож у нас було... і ми все ще певною мірою намагаємося пропрацювати це щодо відокремлення штатів, що є частиною розгляду цього як частини безпеки, це відокремлення штату кожного, тому це лише їхній штат. Але NT дійсно має безпеку, і вона мала вбудовану безпеку, тоді як Windows 95 не мала.

Сейверс: Отже, настає кінець DOS Windows - далі йти не може. І куди NT вплине на майбутнє так званих персональних операційних систем?

Катлер: Де це... о, ви маєте на увазі, як...

Сейверс: XP, 7 і так далі.

Катлер: Ну, дозвольте мені сказати вам, це все NT. Немає нічого, що не є NT. Win 10 - це NT. Це все те ж саме. Це еволюція тієї самої кодової бази, яка сягає 1988 року. На цьому шляху є кілька цікавих відхилень. Якщо ви хочете поговорити про це прямо зараз, або трохи пізніше, тому що я збирався почати...

Сейверс: Беріть той напрямок, який хочете взяти.

Катлер: Я збирався сказати, що станеться після NT 4.0.

Сейверс: Добре.

Катлер: Після NT 4.0 штат NT зріс до 400 осіб. І я начебто на межі того, що, можливо, я не хочу керувати 400 людьми. Можливо, я хочу просто попрацювати над важливими технічними речами. Тож у NT 4.0 я вирішив, що я більше не керую системою, що хтось інший буде керувати системою. І я стаю індивідуальним дописувачем. І бути індивідуальним учасником відтоді означало, що я робив те саме, що й раніше, але не мав із собою інших речей. Отже, наступна система, яку ми виробляємо, це Win 2K. Windows 2000. І Windows 2000 була, ймовірно, однією з перших систем, яку ми справді створили – як окрему серверну систему, SKU сервера від персонального SKU. Я не знаю, чи ми виготовили SKU сервера, можливо, ми виготовили SKU сервера для NT 4. 0 теж, але 2000 був більше орієнтований на це, на написання серверних програм. Win 2K була ще однією чудовою системою щодо надійності та всього іншого. І моєю частиною цього були просто будь-які нові функції, які ми додали в ядро, продуктивність, нічого особливого. І тоді ми відправили це в 2000 році, і в 2000 році є хлопець, який відповідає за групу споживачів, і є хлопець, який відповідає за групу серверів. Вони працювали разом під керівництвом іншого хлопця над створенням системи. Але хлопець, який відповідає за Групу споживачів, вирішує, що споживачам не потрібна якість, яка потрібна групі серверів. І що список функцій Server Group, які вони хочуть включити в наступний випуск, значно перевищує те, що їм потрібно для наступного споживчого випуску. Тож ми розділили кодову базу. Ми розділили його на XP, а іншою була кодова база Server 2003. І це виявилося не вдалим рішенням. І що сталося, у кодовій базі Server 2003 ми виправили всі проблеми безпеки, які у нас виникали. Ми додали функції сервера, і врешті-решт вийшло майже так поставляється одночасно з кодовою базою XP. І кодова база XP постачається з деякими новими елементами інтерфейсу користувача. У ньому була нова кнопка «Пуск» і деякі інші речі. В основному це була робота з інтерфейсом користувача. Але він також поставлявся з багатьма проблемами безпеки та більше помилок, ніж Server 2003. І я працював переважно на нашому Server 2003. І приблизно в цей час – я не пам’ятаю точного дня, але це було трохи після 2000 року, AMD прийшов до нас і сказав: «У нас є розширення для архітектури x86, яке розширить її сумісність до 64 бітів. Ви зацікавлені?» І одна з речей, яку я тут не згадав, це додавання ще однієї платформи в Win 2K, а саме Itanium. Ми мали підтримку Itanium у Win 2K, і Itanium запускав двійкові файли x86, 32-розрядні двійкові файли, але він не запускав їх на швидкості. Тому було покарання за швидкість. Плюс той факт, що Itanium ніколи, ніколи не був таким швидким, як найшвидший x86. Тож пропозиція AMD про це розширення виглядала добре. І ми начебто подивилися на це і сказали: «Ну, це виглядає досить цікаво. Знаєте, чому б вам не повернутися і не повернутися, коли у вас все буде надійніше, і ви думаєте, що захочете його побудувати ." Тому вони повертаються приблизно через шість місяців і кажуть: «Ось воно». Я дивлюся на це і кажу: «Хлопче, це чудово! x86 працює на швидкості». Ми можемо виготовити невелику річ, як-от AME, ми можемо створити невелику оболонку-обгортку, яка просто виконує 86 двійкових файлів, і вони запускатимуть її незалежно від швидкості процесора. 64-бітний матеріал працюватиме зі швидкістю процесора. За винятком того, що він матиме більший адресний простір". Тому я сказав: "Це досить добре. Нам потрібно поговорити про те, збираємося ми це робити чи ні". Тож я не знаю, минуло небагато часу, і нічого не відбувалося. І я підійшов до Алчіна і сказав: "Ми роблю це. Ми просто збираємося це зробити. Я збираюся це зробити. У мене є пара хлопців, і ми це зробимо". Тож четверо з нас почали це робити. І ми зробили багато підготовки, щоб зробити тип даних нашої кодової бази нейтральним щодо розміру покажчика, через Itanium, а також тому, що ми фактично свого часу створювали 64-розрядну систему Alpha. А потім Compaq сказав: «Ми більше не створюємо їх», тому ми припинили це робити. Тож ми почали з того, що стало версією x64 NT на початку 2000-х. У той же час AMD розробляла архітектуру. І ми отримали досить хорошу думку щодо деяких справді важливих речей. Я вважаю, що в архітектуру процесора введено близько шести особливостей, які я вважаю абсолютно важливими, і це було їх у відносній адресації. І це 32-бітове зміщення, тож це означало, що якщо ми хочемо сказати, що наші двійкові файли ніколи не перевищують два гігабайти, то це зміщення завжди охоплюватиме двійковий файл. Тому вони вводять відносну адресацію. Вони ввели деякі інші речі, які були орієнтовані на продуктивність. І в мене були дуже хороші стосунки з головним хлопцем з мікрокоду, я маю на увазі, Кевін МакГрат був просто чудовим. Повертаючись до того, наскільки важливим було це 32-бітне заміщення. тож це означало, що якщо ми хочемо сказати, що наші двійкові файли ніколи не перевищують два гігабайти, то це зміщення завжди охоплюватиме двійковий файл. Тому вони вводять відносну адресацію. Вони ввели деякі інші речі, які були орієнтовані на продуктивність. І у мене були дуже хороші стосунки з головним хлопцем з мікрокоду, я маю на увазі, Кевін МакГрат був просто чудовим. Повертаючись до того, наскільки важливим було це 32-бітне заміщення. тож це означало, що якщо ми хочемо сказати, що наші двійкові файли ніколи не перевищують два гігабайти, то це зміщення завжди охоплюватиме двійковий файл. Тому вони вводять відносну адресацію. Вони ввели деякі інші речі, які були орієнтовані на продуктивність. І в мене були дуже хороші стосунки з головним хлопцем з мікрокоду, я маю на увазі, Кевін МакГрат був просто чудовим. Повертаючись до того, наскільки важливим було це 32-бітне заміщення.

Можливо, ви не подумаєте, що це буде важливо, але одним є код, незалежний від позиції. Важко написати код для 64-розрядної архітектури, який не є позиційно-незалежним. Це означає, що одна з головних речей безпеки, яку ви робите, це те, що називається ALSR, тобто рандомізація переміщення адресного простору. Отже, ви берете зображення та рандомізуєте його місце в адресному просторі. Ми повинні перемістити його, коли ви це зробите. Ну, якщо немає переїздів, то й робити не треба, чи не так? Зараз все ще можуть бути переміщення, але щоб мати незалежний код, вам потрібно, щоб код був незалежним, на відміну від даних. Ви завжди можете створювати покажчики на дані. Так чи інакше, ми вирішили зробити це з кодовою базою Windows 2003. Тим часом XP надійшов, і ми виробляємо систему для споживачів під назвою Longhorn. Я назвав це: "Це Маттерхорн?" Через те, що в ньому було так багато помилок і було так важко його запустити, що врешті-решт дійшло до того, що я переконав Оллчіна, я сказав: «Ми повинні просто смітити цю кодову базу та почати спочатку з кодовою базою Windows 2003, оскільки нова кодова база». І ми це зробили. Ми почали спочатку. Ця система стала Vista. І Vista була – те, як це було доставлено з системою – була Vista. Але насправді ми надали підтримку x64 як пакет оновлень для Windows 2003 Server. Це була Windows 2003 Server SP-1. І він мав кілька нових SKU. І це були 64-розрядні SKU.

Був професійний настільний SKU, а потім був серверний SKU. І це виявилося дуже вдалим. Я маю на увазі, що зараз усе 64-бітне. Майже все. Ну, я не можу сказати, що телефон не 64-бітний, тому що...

Сейверс: Мобільний телефон все одно.

Катлер:Виявляється, мобільний телефон переходить на 64-розрядну ARM. Тому вони хочуть більше 4 гігабайт фізичного адресного простору. Тому вони збираються перейти на 64-розрядну ARM. Є місця, де я думав, що 32-бітні версії повністю зникнуть. Але є такі речі, як мобільні телефони, де менші розміри вказівника фактично означають менше пам’яті. Ви використовуєте менше пам'яті. А на телефонах менше пам’яті означає менше споживання енергії. Менше споживання енергії означає щасливіших користувачів. Тож тим часом тут ми постачаємо 2003. Але перед тим, як відправляти 2003, ми знову маємо повернутися до XP. І нам потрібно докласти величезних зусиль для XP, щоб привести його до всіх покращень безпеки, які ми внесли в серверну систему. Отже, в основному ми робимо XP Service Pack 2, який був фактично випуском. Перевипуск цього програмного забезпечення. Таким чином, це підводить нас до точки, де... і знову, це все NT. Ти вмієш читати, як ти читаєш Мері Джо Фолі-- я не знаю, чи ти знаєш, хто вона? Вона написала про Microsoft назавжди. І це схоже на: «Це аце не нова операційна система. Це еволюція. Щоразу, коли Linux виходить із новим випуском, це не нова система, це еволюція старої системи. Тож XP SP-2 була справді новою системою, тому що це був перевипуск майже кожного окремого двійкового файлу. Потім ми повернулися до XP Service Pack 2, потім ми зробили випуск x64. А потім ми повернулися та повернули ресурси до Vista. І так Vista вийшла базовою - як 64-розрядна система і 32. Я думаю, що Vista насправді також підтримувала Itanium.

Тим часом одна з речей, яку ми залишили тут, це те, що системи RISC відключалися. І ось чому я думаю, що вони кинули. Я думаю, що хлопці з RISC були настільки зосереджені на простій архітектурі з простою реалізацією, що Intel отримала цю архітектуру, вона трохи складна, але у них багато транзисторів, у них багато дизайну, і вони мають багато досвіду перевірки, давайте поставимо це транзистори працювати, щоб все працювало швидше. А робота швидше — це такі речі, як дуже складне передбачення розгалужень, краще кешування. Ви знаєте, набір-асоціативне кешування. І просто всякі речі, спекуляції і все таке. Але хлопці з RISC кажуть: «Ну, ви знаєте, ми насправді не хочемо робити це. Знаєте, ми хочемо, щоб це було просто». Тож те, що RISC має перевагу продуктивності, просто зникло. Це пішло, тому що ніхто не мав ресурсів, щоб попрацювати над архітектурою чіпа та дизайном чіпа, як це робила Intel, і вони не мали ресурсів, щоб створити великі проекти з усіма наявними транзисторами. Я маю на увазі, що зараз вони будують мільярд транзисторних мікросхем, так? Отже, і хлопці з RISC збираються... вони хочуть мати можливість сказати: «Дивіться, подивіться на це! Ми створили цю машину з 300 000 воротами». правильно? Мовляв, "Ну і що?" І все з процесорами Intel зараз і процесорами AMD дійсно складне. Це дійсно так. Порушення виконання і все таке інше. А хлопці з RISC, знаєте, вони не хочуть цього робити. Я вважаю, що RISC-системи пішли, тому що вони не змогли запропонувати цінову продуктивність, яку могли б отримати системи Intel. Вони не змогли забезпечити сумісність через лінію. Я маю на увазі, у нас були запущені всі ці програмні емулятори. І одна з речей, які ми зараз робимо в Itanium, і, власне, Alpha також започаткувала це, це бінарна перекомпіляція. Там, де ви берете двійковий файл, ви берете двійковий файл x86, ви запускаєте його через двійкову перекомпіляцію, створюєте інший двійковий файл, який працює під спеціальною системою емуляції, яка здебільшого виконується на швидкості процесора. Тому що він перекладає все, що може знайти який працює під спеціальною системою емуляції, яка здебільшого виконується на швидкості процесора. Тому що він перекладає все, що може знайти який працює під спеціальною системою емуляції, яка здебільшого виконується на швидкості процесора. x86-код до альфа-коду або будь-яка ціль, але все ще може бути кілька фрагментів, тож ви фактично запускаєте справжній двійковий файл. І іноді вам доводиться фактично перемикатися в режим, який фактично емулює інструкцію, але в більшості випадків він виконується. Отже, бінарна перекомпіляція пройшла довгий шлях, і нам було б набагато краще. Але все одно у вас є двійкова перекомпіляція, а потім ви говорите: «Я зроблю повторну компіляцію, і вона просто покладе це в магазин, так? Тоді це працюватиме». Ну, це не так, розумієте? Ви повинні піти і переконатися. Ви повинні перевірити і переконатися. Отже, це подвоєння роботи. Тож я думаю, що популярність RISC-архітектури зникла через усі ці речі. Тепер ARM закріпилася в телефонах і в деяких мобільних пристроях. Але продуктивність ARM далеко не така, як у x86, як від AMD, так і від Intel. І ви знаєте, ARM намагається туди потрапити. Вони намагаються підвищити продуктивність. Але насамперед вони були націлені на владу. І ви використовуєте процесори ARM у програмах, де вам не потрібна велика потужність. Можливо, вам потрібна маленька фішка. Одна з речей, які відбулися, це певною мірою Intel і AMD: «У нас є мільярд транзисторів. Ми просто повинні створити такий великий чіп. Останній був такого розміру. Наступний має бути такого розміру. .. Хоча ми маємо в чотири рази більше транзисторів, ми збираємося побудувати їх того самого розміру», чи не так? Ну, хлопці з ARM насправді цього не зробили. Хлопці з ARM мають портфоліо з великою кількістю мікросхем різного розміру. Отже, якщо ви будуєте годинник,

Сейверс: Так

Катлер: Але Intel і AMD ніколи не зверталися до цього: «Ну, візьмемо... тепер ми можемо створювати ту саму функціональність у чверть розміру; можливо, це був би хороший продукт».

Сейверс: Ну, вся ця технологія обробки напівпровідників із кінцевою грою з P4 полягає в тому, що ми отримуємо, можливо, 4 гігагерци, а чіп працює від лампи розжарювання. Отже, тепер переходимо до багатоядерності. Отже, це велика подія у світі операційних систем, і ми матимемо чотири процесори для гри. Як це почало потрапляти в середовище?

Катлер: NT була з першого дня, коли ми створили NT, щоб бути MP. І наш початковий, наш прототип RISC, або наш референс, був MP. Отже, ми були MP з першого дня. Отже, ядра нічим не відрізняються від... насправді є два види ядер. Ви думаєте про ядра як про автономні ядра або багатопотокові ядра. Якщо це багатопотокові ядра, то це набір контексту, який є потоком, і апаратного ядра, яке фактично виконує цей контекст.

А потім ви перемикаєтеся між цими контекстами. І Intel це зробив, це називається SMTs-- ну, багатопотоковість. Просто назвіть це багатопотоковістю. Intel зробила це на ранньому етапі, але ми вже мали підтримку MP. Тож єдине, що було на кшталт кривої, це те, що SMP підвищив паралелізм, але не обов’язково продуктивність.

Оскільки у вас в основному є така ж кількість можливостей виконання, як і раніше, у вас є лише кілька контекстів, які ви можете запустити з цим. Тепер ви можете отримати перевагу від затримок, наприклад промахів кешу, коли ви можете сказати: «Ну, цей промах кешу... Я пропустив у кеші цей набір контексту, я можу переключитися на інший контекст», і це можна негайно виконати. Можливо, у вас був промах кешу раніше, а тепер ці дані там. Тож ви можете отримати, можливо, 15 відсотків. Ви також можете втратити п'ять відсотків або десять відсотків. Настільки дуже непередбачуваний, так що це ніби кинуло нам кривий м’яч. AMD пішла іншим шляхом, і вони зробили те, що було-- те, що вони назвали CMT. Багатопотоковість отримала назву SMT, Symmetric Multithreading.

А інший називався CMT, а CMT був багатопроцесорним процесором. Що фактично розміщує більше ніж один процесор на чіпі. Отже, оригінальні 64-розрядні мікросхеми AMD були двопроцесорними. Тож у них було два справжні процесори. З того часу всі вони перейшли на цю багатоядерну річ, де у них насправді є ядро

логіка, яка поділяє деяку іншу частину. Наприклад, вони можуть мати спільний доступ, як і ви, пару ядер із кеш-пам’яттю другого рівня. Тоді всі дві пари спільно використовують кеш L3. І все це зараз є в NT. Скільки рівнів кешу у вас є? Які вони, скількома способами встановлення асоціативності? І все це. Тож ця річ особливо не вплинула на NT, але вплинула на програми. Тому що тепер програми можуть отримати більшу продуктивність, якщо вони багатопотокові. Тож якщо хтось спочатку почав із NT і сказав: «Я матиму лише однопотокову програму», то ці інші процесори... ну, вони просуваються до точки, де ми досягаємо 3,5 гігагерца, і вони все готово до наступного стрибка до 4, і наступного стрибка до 4 не відбувається, тому що ми не можемо побудувати його на 4, тому що у нас був би такий високий струм витоку, що ви маєте рацію, він би світився. Справа б світилася. Тож ми почали будувати ядра, і тоді це було схоже на змагання, скільки ядер ми можемо отримати на одному кубику. Я не знаю, який найбільший, але він великий. Це як, я не знаю, можливо, 80 або щось подібне. Отже, є багато ядер. Але для самої NT це мало що означає. Зовсім ні. В основному це додатки. це взагалі не так багато значить. Зовсім ні. В основному це додатки. це взагалі не так багато значить. Зовсім ні. В основному це додатки.

Сейверс: Куди нам далі йти?

Катлер: Таким чином, у такій хронології ми знаходимося у Vista, і ми перенацілили Longhorn на одну кодову базу. Тож ми фактично повернулися до однієї кодової бази. І я все ще окремий учасник, і я працював над Vista, я зробив деякі речі для Vista. В основному це стосується x64, тому що я був тим хлопцем, який був ініціатором x64. І звичайно, я кажу, що нас четверо зробили це. Ми зробили багато цього. Ми виконали левову частку цього, але в світі компіляторів були докладені зовсім інші зусилля, де у нас було кілька хлопців у групі компіляторів, які були просто чудовими, і вони чудово впоралися з компілятором, тому там була зовсім інша група людей. Я маю на увазі, я не знаю, чи знаєте ви, скільки людей насправді відповідали за систему x64, але їх було досить мало, можливо, сто людей. Так чи інакше, Vista, ми відправили Vista. І Vista є великою дилемою, тому що це таке: «Чи варто її відправляти чи почати спочатку? Вона виглядає не дуже добре. Вона виглядає не так, як XP. Вона не виглядає так, як усе, що ми робив раніше, це інше». Тож ми відправили його. І з не дуже хорошим сприйняттям ринку. Vista була, мабуть, найгіршою версією серед усіх систем Windows, які поставлялися.

Сейверс: Ну, було ще щось, Боб і ще деякі речі.

Катлер: О, системи Windows.

Сейверс: Так, системи Windows.

Катлер: Ой, Боб. Так, Боб протримався, я не знаю, три-шість місяців. Це було приблизно все. Отже, Vista вийшла на ринок у листопаді 2006 року. Я деякий час працював у групі операційних систем, але пізніше того ж року, я думаю, що це був десь жовтень, хмарні обчислення стали гарячою темою. І хмарні обчислення в основному повертаються в іншу сторону, де, знаєте, у нас був сервер - колись у нас була система розподілу часу, потім ми перейшли на сервери, потім ми перейшли на персональні комп'ютери, а зараз ми повертаємося до централізованого Знову сховище та центральне обчислення, де у нас є десь велика серверна ферма, з якою ви можете якось, ви можете взаємодіяти з будь-якого пристрою, і всі важкі обчислення або важке сховище відбуватимуться на цьому кінці. У нас були серверні ферми в кількох місцях, але вони були спеціально для серверів, або сервери для цього, або що завгодно. Отже, фактично було розпочато інкубаційний проект під назвою Azure. І це було створити систему, яка б забезпечувала a

платформу, яку люди можуть орендувати, де вони можуть орендувати обчислювальну потужність, вони можуть орендувати сховище. і ми вирішили, що це буде віртуалізована система, оскільки ви хочете запускати кілька екземплярів операційних систем, тому її потрібно віртуалізувати. І це було в той час, коли з’явилися перші розширення віртуалізації для AMD і Intel, і вони не зовсім на тому рівні, який ми вважали необхідним.

Зокрема, пейджинг був справжньою проблемою. І системи віртуалізації, які існували-- реалізації віртуалізації, які існували в той час-- це гіпервізори, які в основному створювали тіньові сторінки, тіньові таблиці сторінок. І ми вважали, що прямий переклад кращий. Тож ми вирішили використовувати прямий переклад, який додає більше рівнів перекладу, але він є прямим, і у вас немає дублікатів таблиць сторінок збоку. І AMD була першою компанією, яка їх виробляла. Intel з'явилася пізніше. І ми вирішили, що наш гіпервізор буде базуватися на цьому, і я став відповідальним за гіпервізор для Azure. Ми створили Azure і створили ферму серверів у Квінсі, штат Вашингтон. Я не пам’ятаю, скільки у нас було серверів, але їх було небагато, серверів на десятки мільйонів доларів, це була лише наша тестова система, правда? І ми працювали близько двох років, і наша головна відмінність на той момент полягала в тому, що нас насправді попросили зробити, це створити систему, яка була б платформою як послугою, яка включала б усе те, що вам потрібно зробити, якщо у вас є сервер. У вас проблеми з керуванням конфігурацією. Де ви повинні відстежувати операційну систему, яку ви використовуєте, її версію, версії всіх програм тощо. І тоді, якщо у вас є кілька таких, ви повинні оновити їх усі разом. Тож ми створили всю інфраструктуру, щоб робити все це, думаючи, що це буде велика річ, яку люди дійсно хочуть. І певною мірою це так, тому що ви не хочете робити це вручну. Ви не хочете вручну мати, сказати: «Ах, боже, у мене є 150, у мене є 2, 000, у мене 10 000 серверів, і вийшло нове оновлення для операційної системи. Ну, я маю оновити кожен із них, чи не так?" Чи хочу я сидіти там і робити це? Ну, ні. І були деякі внутрішні люди в Microsoft, які справді розробили деякі інструменти для цього. І вони в основному керували нашими веб-сервісами. Тож ми вирішили створити ще один набір інструментів, і, я думаю, близько... я думаю, приблизно через два з половиною роки проекту, ми робили це досить довго що Стів Балмер вирішив: «Ну, Боже, ми повинні зробити це продуктом зараз». Тож ми зробили Azure продуктом. І я точно забув, коли вперше... я думаю, у 2010 році ми представили Azure, це був Платформа як послуга. На цьому етапі ми вийшли з інкубації, і нас хвилює, у вас є кілька центрів обробки даних, оскільки вам потрібна потрійна надлишкова логіка для всього сховища. І, звичайно, ми хочемо робити це на міжнародному рівні, тому ми будуємо центри обробки даних у Німеччині або в Європі. Ми будуємо дата-центри на Сході, на Далекому Сході. Тоді у вас виникають проблеми, пов’язані з тим, що ми не можемо мігрувати – ви не можете копіювати жодні дані в геополітичних регіонах.

Сейверс: Перевезення до Канади коштує грошей. <сміється> Катлер: Ну, головним чином через геополітичні проблеми... Сейверс: Так, так, цікаво.

Катлер: Ви знаєте, якщо ви зберігаєте копію даних з Німеччини, які належать німецькому уряду, вони справді не хочуть, щоб вони зберігалися на серверах у Техасі, чи не так? Тому ми випустили першу версію Azure. І в групі серверів змінилося керівництво, і Azure очолив хлопець, який керував групою серверів. І в той час пара з нас вирішила, що ми підемо працювати на Xbox. І іронія роботи над Xbox полягає в тому, що я одного разу надіслав Стіву Балмеру листа з такими словами: «Стіве, я отримав

ідея. Чому б нам не взяти цей мільйон доларів на тиждень, який ми втрачаємо на Xbox, і не вийти на автостоянку в п’ятницю ввечері, не влаштувати багаття та засмажити хот-доги та зефір? Ми можемо взяти людей, які працювали над цим, і поставити їх на те, що справді дасть хороші речі, і ми заощадимо всі ці гроші!» Звичайно, це була просто нахабна річ. Тож ось я як...

Сейверс: Перехід на темну сторону?

Катлер: Через кілька років я перейшов на темну сторону. Тож Xbox був справжньою новою річчю для мене, тому що це робота над чимось, де безпека значно відрізняється від безпеки будь-чого іншого. Ви думаєте про безпеку, як ви зазвичай думаєте про це фізично - у вас фізично є машина. Це ваше, це безпечно. І тепер ви просто турбуєтеся про те, щоб не допустити всіх тих інших людей, які можуть вторгнутися в нього через Інтернет чи будь-що інше. Xbox зовсім інший. Ми хочемо захиститися від людей, у яких є паяльник і логічний аналізатор. Вони не можуть зламати систему. Якщо вони щось зроблять, щоб змінити систему, вона негайно побачить, що її було змінено, і зробить те, що називається «замуруванням». Він сам себе замурує. Тепер він стане цеглою. Це вже не Xbox, це цегла. Тож будувати таку систему цікаво. І це вимагає багато деталей і уваги до безпеки. Багато обладнання. Не обов’язково з точки зору вартості, але багато апаратного забезпечення, багато шифрування.

AMD займається створенням нестандартних SOC. І для цього вони створили спеціальний SOC, який має вісім ядер, і вони розділені на чотири двоядерні групи. Але він також має процесор безпеки ARM. Отже, безпечне завантаження насправді безпечне. Ви не можете вирішити, що ви збираєтеся припаяти деякі частини. Ви не можете вирішити, що знімаєте деякі частини, перепрограмуєте їх і повертаєте назад. Він виявить це, все зашифровано. Він працює з гіпервізором, тому в системі існує рівень захисту гіпервізора. Він працює - це триголова операційна система, де вона фактично запускає три віртуальні машини, одна називається системою хосту, яка спілкується з гіпервізором і є частиною довіреної комп’ютерної бази. І гіпервізор насправді, ви можете подумати про це, він працює на голому апаратному забезпеченні, але під егідою процесора безпеки. Ви знаєте, процесор безпеки має можливість просто блокувати певні частини обладнання, щоб ви навіть не могли їх побачити. Отже, якщо до апаратного забезпечення буде доступний лише процесор безпеки, він має можливість це зробити. Він має можливість просто зупинити процесор. Він має великий контроль над тим, що відбувається.

Сейверс: Тож трохи відступіть і скажіть: "Чому?"

Катлер: Гаразд, питання, яке ми обговорювали, було: "Навіщо весь цей захист на Xbox і зробити так, щоб... щоб власник не міг вкрасти?" І відповідь: «Піратство». Ігри Xbox називаються іграми з рейтингом Triple-A, і ігри з рейтингом Triple-A означає, що вони дуже чуйні, це ігри з високою частотою кадрів. Як правило, люди, які їх виробляють, витрачають багато грошей на їх виготовлення. І вони не схожі на комп’ютерні ігри, де, як правило, у комп’ютерних іграх є піратство, але вони отримують великий сплеск, коли їх випускають, і, я думаю, вони вважають, що це компенсує будь-яке піратство, яке вони отримують. Але гра з рейтингом Triple-A коштує високо, вона може коштувати сто доларів. І ми гарантуємо, що люди не можуть піратити ці ігри. І ми за це дійсно отримуємо гроші.

Сейверс: Добре. Отже, ви говорите про всі функції безпеки, і ви працювали над гіпервізором.

Катлер: Я працював над гіпервізором, і ви знаєте, що гіпервізор ізолює всю пам’ять. Робить усе планування. Однією з особливостей Xbox є те, що я маю на увазі, як правило, операційну систему, якою ви хочете поділитися. На Xbox ви не завжди хочете ділитися. І існує багато фактичних фізичних розділів системи, залежно від того, що ви робите. Якщо ви використовуєте ігри з рейтингом Triple-A, ми візьмемо набір ядер і присвятимо їх грі у віртуальній машині. Тому зараз вони не мають справу з перешкодами, які вони отримують через інші речі, що відбуваються в операційній системі. І є багато побутових речей, які відбуваються. І інші речі, які відбуваються, Xbox полягає в тому, що ви насправді можете запускати гру і одночасно переглядати LiveTV, або навіть одночасно спілкуватися по Skype, або запускати Internet Explorer. І щоб вони не заважали один одному. Отже, якщо ви запускаєте гру, і вона на передньому плані, у вас є шість ядер, присвячених вам. Якщо ви запускаєте гру, і вона працює у фоновому режимі, іншими словами, ви більше зосереджені на перегляді телевізора, тоді у вас є чотири ядра, а інше середовище має чотири ядра. Отже, у нас всього вісім ядер. Тому ми постійно змінюємо ці ядра. І гіпервізор робить усе це за командою головної системи. Хост-система стежить за тим, що відбувається. Тож думайте про це так, як про віртуалізацію, оскільки ви використовуєте кілька операційних систем. Або ви можете розглядати Xbox як просто віртуалізацію. Але насправді це не так, тому що все це операційна система, яку ми називаємо Hydra. І справді працює ці три різні ОС, або три різні віртуальні машини, добре? І одна з них, називається системна ОС, — це наше середовище спільних ресурсів, де ви насправді можете запускати речі, схожі на те, що ви запускаєте LiveTV, або Netflix, або Hulu, чи будь-що там, і воно має весь інтерфейс користувача. Отже, усе, що ви робите зі своїм ігровим контролером, взаємодіє з чимось у цій конкретній операційній системі. Але всі драйвери пристроїв і все це є в головній ОС. Отже, між двома або трьома є певний зв’язок через спільні буфери, і гра знаходиться тут, у іншій віртуальній машині, добре, зі своїми власними ресурсами тощо. Тому пам'ять окрема. Це не схоже на систему сторінок за запитом, де... як система розподілу часу, де ви крадете сторінки в Джо, щоб віддати їх Саллі, чи не так? Вони отримують те, що отримують, тому кожного разу, коли ця гра запускається, вона працює однаково. Аудіо не глючить, відео не глючить. І, звичайно, за цим стоїть досить непогане обладнання GPU.

Сейверс: Отже, ви повністю зацікавлені в майбутньому Xbox? Або у вас щось інше?

Катлер: Зараз я більше ні на що не дивлюся. Я просто намагаюся не відставати від того, що ми плануємо робити в майбутньому. Я маю на увазі, найбільше, що я можу сказати про це наразі, це те, що це еволюційний характер. Є думки про те, що нам робити? Чи справді у нас повинна бути консоль, чи ми дійсно повинні спробувати покращити середовище ПК, щоб мати можливість запускати ці ігри з рейтингом Triple-A, що б це означало? Це не буде таким безпечним. Наприклад, на Xbox є купа сертифікатів, які ви отримуєте, купуючи один, які говорять про те, що ви можете робити. Що ж, якщо ви споживач, ви отримуєте Xbox, на якому можна грати в ігри, і ви можете робити інші речі, для яких є програми. Ви не можете запускати налагоджувачі ядра, ви не можете робити нічого з цього. Тому у людей немає можливості здійснювати такі атаки. Але в операційній системі ПК це неможливо виключити, тому що хтось купує ПК і каже: «Комп’ютер у мене є. Він мій». На щастя, з того дня, як ми представили Xbox, і до цього часу люди, які купують Xbox, звикли до того факту, що це середовище насправді не є їхнім бажанням. Вони не можуть завантажити драйвери пристроїв, вони не можуть вставити код в операційну систему. Типові атаки, які хтось може здійснити через Internet Explorer або браузер, неможливі. Або вони суттєво пом’якшені способом розшарування в системі. Однією з речей, які робить гіпервізор, є те, що ми робимо все це Типові атаки, які хтось може здійснити через Internet Explorer або браузер, неможливі. Або вони суттєво пом’якшені способом розшарування в системі. Однією з речей, які робить гіпервізор, є те, що ми робимо все це Типові атаки, які хтось може здійснити через Internet Explorer або браузер, неможливі. Або вони суттєво пом’якшені способом розшарування в системі. Однією з речей, які робить гіпервізор, є те, що ми робимо все це

через-- я не буду називати це криптографією, але це безпечне хешування-- ми використовуємо вкладену сторінку, що означає, що гіпервізор має реальну таблицю сторінок і реальні біти доступу. І віртуальна машина має, на її думку, таблиці сторінок і біти доступу, але вона не може ввімкнути біт виконання, якщо його не ввімкнув гіпервізор. І їхній гіпервізор увімкне його, лише якщо він знаходиться на сторінці, яка має хеш, який ми розпізнаємо. Тому ви не можете вставити код в операційну систему. Якщо ви виявите переповнення буфера, то найкраще, що ви можете зробити, це, можливо, перескочити кудись, де ви зможете знайти гаджет. А ґаджет — це купа байтів, які можна виконати, але не обов’язково на межах інструкцій, які виконують якісь дивні речі. Ви знаєте, оскільки x86 є машиною зі змінною довжиною команд, немає приємних чітких меж інструкцій, тому ви можете стрибати в середині інструкцій. Зазвичай ці люди виявляють переповнення буфера. Вони стрибають у середину одного з цих гаджетів, який потім перескакує кудись ще в коді, який вони завантажили або щось таке. Але ви не можете зробити це на Xbox.

Сейверс: Тож переходимо до прогнозів щодо майбутнього. Яке майбутнє операційних систем?

Катлер: Це гарне запитання.. І VMS все ще живий після якихось 35 років. Трохи більше 35 років.

Сейверс: Я думаю, що 37.

Катлер: Так, 37 років. VMS, я не вірю, майже така велика, як Windows. Windows, знаєте, мені неприємно гадати, скільки рядків коду в Windows, але я думаю, що це більше мільярда. Може бути кілька мільярдів. Він величезний. Linux менший. UNIX як би пішов. Я справді думав, що Linux піде тим самим шляхом, що й UNIX, коли всі брали UNIX, отримували на нього ліцензію, а потім намагалися додати свою цінність, зробивши його несумісним з усіма іншими версіями UNIX, що для нас чудово. Тому що просто зробила так, що була фрагментація. Linux, здається, не пішов таким шляхом. Я маю на увазі, що вони, здавалося, вважали себе сумісними. Але все одно це також величезна система. Вона не така величезна, як Windows, тому що за її плечима ще немає 28 років. Тепер у нього 15, або будь-яке інше. Але через десять років це теж буде. Є багато дрібниць, які ви можете зробити, наприклад, є люди, які створюють маленькі операційні системи для керування двигуном чи щось подібне. Але побудувати велику операційну систему і створити певний рівень сумісності для запуску всіх цих програм, які існують, є дуже великим зусиллям. Це може бути зусилля, яке навіть уряд США не захоче взяти на себе. Отже, думка про те, що з’явиться нова операційна система на рівні Linux або навіть UNIX або навіть NT, виглядає так, що це буде важко. Я не думаю, що це станеться дуже – якщо це станеться, то пройде дуже довго. І це буде. Якщо це станеться, то це станеться тому, що складність кодової бази зростає до точки, коли з’являється таке: «Чи хочемо ми розв’язати складну кодову базу, чи ми хочемо просто викинути її й почати заново?" І люди можуть сказати: «Ну, ми просто хочемо викинути й почати спочатку». Однак викинути його та почати все заново не означає, що ви можете просто втратити сумісність, оскільки ви не можете. Ви не можете смітити сумісність.

Сейверс: Чи великі дані є розгалуженням того, що таке операційна система?

Катлер: Ні, великі дані, як я розумію великі дані, це використання додатків для візуалізації, аналізу, сортування великих наборів даних, щоб знайти зв’язки, які інакше ви не змогли б знайти. Це насправді не проблема операційної системи. Це більше стосується аналізу даних. І це, знаєте, це-- у нас є такі величезні набори даних. Ми робили це в DuPont. Ми робили – одну з речей, які вони робили в DuPont, вони створили свою власну програму під назвою RAMR, а RAMR означає, о, регресійний аналіз і множинне придушення, або щось таке, що було, в основному, весь час на цих хімічних заводах, ви намагаєтеся взяти дані, які збираєте, і побачити, які змінні навколишнього середовища, людські незмінні, робочі змінні, хімічна чистота тощо, що з чим корелює, щоб ви могли піднятися до оптимуму на якійсь кривій.

Сейверс: На якомусь процесі?

Катлер: На якомусь процесі, так? І отже, це частина відділу інженерних послуг була... була група математики та статистики, яка робила саме це, чи не так? Тож ми робили це, але тепер люди починають дивитися на це з точки зору маркетингу, знаєте, де ви націлюєте рекламу, і багато інших речей. І я не думаю, що це, як така, річ операційної системи. Я маю на увазі, що в якийсь момент у нас може бути-- насправді ми, ймовірно, вже маємо великі хмарні програми, які ви можете придбати, запускати та надавати свої дані.

Сейверс: Над цим працюють тисячі процесорів.

Катлер: Так, добре, одна з приємних речей у хмарі – це еластичність. Ви можете сказати: «Мені зараз потрібен лише один процесор, одне ядро». Або ви можете сказати: «Я хочу 10 000». І ви можете отримати 10 000 процесорів, які працюють паралельно. І, можливо, вони будуть працювати як кілька екземплярів віртуальних машин або вони можуть працювати як багатопроцесорні в межах віртуальної машини, чи не так? Так.

Сейверс: Чи є надія на загальну декомпозицію програм на паралельну обробку?

Катлер: Ну, ви знаєте, люди продовжують відмовлятися від цих речей, і це стає все краще. Люди робили це, ви знаєте, Кен Кеннеді в Rice, Кен Кеннеді був великим хлопцем для Dusty Deck FORTRAN, і сумно відомим. І я впевнений, що він повинен бути хлопцем. Хіба він не стипендіат ?

Сейверс: Не знаю, ні.

Катлер:Був частиною стартапу Tera/Cray. Він працював над Dusty Deck FORTRAN у 1970 році? Де вони беруть FORTRAN і намагаються взяти Dusty Deck FORTRAN і скомпілювати його, щоб його можна було векторизувати та робити паралельно. Там просто багато чого відбувається. Я думаю, що зараз відбувається більше того, щоб не обов’язково брати старі речі та змусити їх працювати паралельно, а щоб завжди створювати нові речі для паралельної роботи. Одна з речей у Windows 10, насправді, я думаю, що це також було в Windows 8, це планування режиму користувача, щоб зробити так, щоб ви могли мати десятки тисяч потоків, і ви самі плануєте їх, щоб були мінімальні витрати , тому що ви знаєте, як ви перемикаєтеся. Не обов’язково мати десять тисяч процесорів, у вас може бути лише 20 процесорів. Але у вас є десять тисяч справ, які ви можете запланувати. Отже, є певний рух у напрямку, який частково був рушійною силою, це була річ ядра проти частоти, де люди зрозуміли, я не знаю, коли, це було приблизно п’ять років тому, або близько того, ми зрозуміли, що-- коли-- насправді , Intel сказав: «Протягом десяти років ми матимемо процесор на 10 гігагерц». А потім вони сказали: «На жаль, ми, ймовірно, ніколи не матимемо процесор із 10 гігагерцами через цю проблему, якщо ми не знайдемо інший спосіб створювати транзистори». Таким чином, можливість запускати кілька потоків і планувати їх самостійно стала чимось, що, принаймні, наші люди вважали важливим для існування Intel сказала: «Протягом десяти років у нас буде процесор з частотою 10 гігагерц». А потім вони сказали: «На жаль, ми, ймовірно, ніколи не матимемо процесор із 10 гігагерцами через цю проблему, якщо ми не знайдемо інший спосіб створювати транзистори». Таким чином, можливість запускати кілька потоків і планувати їх самостійно стала чимось, що, принаймні, наші люди вважали важливим для існування Intel сказала: «Протягом десяти років у нас буде процесор з частотою 10 гігагерц». А потім вони сказали: «На жаль, ми, ймовірно, ніколи не матимемо процесор із 10 гігагерцами через цю проблему, якщо ми не знайдемо інший спосіб створювати транзистори». Таким чином, можливість запускати кілька потоків і планувати їх самостійно стала чимось, що, принаймні, наші люди вважали важливим для існування здатний використовувати паралелізм, властивий програмам, із самого початку, замість того, щоб говорити: «О, ми візьмемо цю стару програму і змусимо її працювати паралельно».

Сейверс: Що ви думаєте про ШІ? Поточний стан ШІ?

Катлер: Ну, ви знаєте, штучний інтелект зараз робить деякі речі, які я думаю... ви знаєте, коли почався штучний інтелект, здійнявся гучний галас: «О, ну, боже, це не мине довго, тому що комп’ютер зробить усе!» І незабаром ми подумали: «Ну, комп’ютери ніколи нічого не зроблять!» Але зараз існує багато революційних штучних інтелектів. Добре, я б назвав це штучним інтелектом, я не знаю, чи ви б назвали це штучним інтелектом, але я думаю, що перекладач Skype абсолютно неймовірно щось таке, що просто неймовірно. Ось де... Я не знаю, знаєте ви про це чи ні? Тут ви можете бути французом, а я можу бути іспанцем, і ми можемо говорити один з одним, і Skype автоматично перекладатиме це-- коли я розмовляю, перекладайте мою мову на вашу мову. Це неймовірно!

Це неймовірно.

Сейверс: Скільки кандидатських дисертацій було написано про це до того, як це сталося? <сміється>

Катлер: Багато. Багато. І ви знаєте, тепер у Windows є розпізнавання відбитків пальців для входу. А Деббі ніби вона щойно отримала новий телефон-- вона впустила свій телефон, я думаю, вчора вранці, і зламала його. І вона каже, що вона отримала свій новий телефон і на ньому Windows 10. І вона каже: «Погляньте на це! Я можу ввійти за допомогою свого ока! Моїм відбитком ока. Моєю райдужною оболонкою можна ввійти в систему». Тож я вважаю, що штучний інтелект справді злетів. Ви знаєте, інша річ, я думаю, ШІ, я думаю, що ви повинні думати про машини, керовані комп’ютером, як ШІ. І знаєте, я думаю, що це чудово. Але я бачу, що на одному з цих речей, які ви мені дали, було запитання: «Чи будете ви коли-небудь сидіти на задньому сидінні автомобіля зі штучним інтелектом?» І я думаю, що відповідь на це питання: «Недовго».

<сміх> Я скажу вам, чому я в це вірю. Я в це вірю, тому що такий штучний інтелект трохи відрізняється від мовлення. Це схоже на різницю між машиною, як-от машиною CAT-сканування, де ви контролюєте цю машину в режимі реального часу, і якщо це керування стає безглуздим, це вбиває когось! На відміну від того, що ми говоримо туди-сюди, ми спотворюємо слово. Це зовсім інша річ, чи не так? Отже, знаючи, наскільки велика і складна Windows і наскільки складний і великий Linux, я думаю, що існує велика ймовірність того, що в програмному забезпеченні є велика кількість помилок. Хіба що надзвичайно просто. Тепер вони, можливо, взяли Linux і зняли його – або що вони взяли – і звели його до такої дрібниці, що вони фактично зможуть довести, що це правильно. однак, Ви знаєте, комп’ютери не на 100 відсотків. Ви знаєте, у них час від часу виникає таке: «Що сталося? Це просто пішло». Ви знаєте, ну, ну, тандем створив системи, які мали потрійну надлишкову логіку чи щось інше. Тому я не знаю. Я нічого не читав про те, чи є у них потрійні резервні контролери в цих системах, які керують автомобілями, але я очікував, що вони є. А інша річ, знаєте, як те, що відбувається, коли – знаєте, одного разу ми в Ланкастері, штат Каліфорнія, і збираємось на іподром, і ми орендували машину від Hertz, яка має NeverLost . І вгадайте що?! Ми втратили NeverLost! І ми його втратили, тому що атмосферні умови були такими, що GPS не міг працювати. Отже, що відбувається, коли ви несетеся по шосе, і виникають такі атмосферні умови, і GPS більше не працює. Ваші параметри близькості працюють, але ви більше не знаєте, куди йдете. Тож я думаю, що є кілька запитань, на які потрібно знайти багато відповідей, перш ніж ми виведемо машини на шосе зі швидкістю 70 миль на годину і скажемо: «Так, ось, ми сядемо на заднє сидіння і подивимось телевізор».

КІНЕЦЬ ІНТЕРВ'Ю